https://imx.ink/agent/Recent content in Agent on 提笔忘字Hugozh-CNCopyright © 2023, Xie Ziyao.Sat, 02 May 2026 18:00:00 +0800https://imx.ink/tech/2026/05/02/software-engineering-three-paradigms/Sat, 02 May 2026 18:00:00 +0800https://imx.ink/tech/2026/05/02/software-engineering-three-paradigms/<img src="https://f005.backblazeb2.com/file/wml5yw8gwgll/20260505/software-engineering-waves.png" alt="软件工程三次范式跃迁：瀑布流 → 敏捷 + DevOps → 人 + 数字员工" style="zoom:50%;" /> <p>这一篇想把镜头拉远一点，问一个更大的问题——</p> <blockquote> <p><strong>整个软件工程 50 多年的历史上，有过几次真正意义上的范式跃迁？我们现在在哪？</strong></p> </blockquote> <p>把答案提前说：<strong>过去 50 年发生过两次，第三次正在发生</strong>。</p> <p>而且这三次之间有一条非常清晰的红线：<strong>软件工程的&quot;硬核&quot;从来没变，变的只是围绕这个硬核的执行层</strong>。理解这条红线，比理解任何具体的工具更重要。</p> <hr> <h2 id="软件工程-10瀑布流1968--2001">软件工程 1.0：瀑布流（1968 — ~2001）</h2> <p>1968 年 NATO 软件工程会议的核心焦虑是——<strong>软件项目为什么总是延期、超预算、质量失控？</strong></p> <p>当时的答案是&quot;缺少工程纪律&quot;。于是瀑布模型诞生了，把软件开发类比为建筑施工：</p> <pre tabindex="0"><code>需求分析 → 系统设计 → 详细设计 → 编码实现 → 测试验证 → 运维交付 ↓ ↓ ↓ ↓ ↓ ↓ 需求文档 → 概要设计 → 详细设计 → 源代码 → 测试报告 → 上线 </code></pre><p>1.0 的<strong>核心假设</strong>：</p> <ul> <li>需求可以在开发前被完整定义</li> <li>每个阶段的产出是下一阶段的输入，回头成本极高</li> <li><strong>人的角色是&quot;按文档执行&quot;</strong></li> </ul> <p><strong>1.0 做对了什么？</strong></p> <p>它建立了&quot;软件开发是工程活动而非艺术创作&quot;的行业共识，引入了阶段评审、文档规范、测试体系，奠定了整个行业的底座。</p> <p><strong>1.0 的天花板在哪里？</strong></p> <ul> <li><strong>假设了需求不变</strong>，但真实世界的需求永远在变</li> <li><strong>反馈周期太长</strong>——从需求到看见可运行软件可能隔 6–12 个月</li> <li><strong>文档成了目的而非手段</strong>——团队花更多时间维护文档而不是解决问题</li> <li><strong>人被流程困住了</strong>——每个角色都在等上游的文档，串行阻塞</li> </ul> <p>瀑布流的本质困境是：<strong>它假设软件开发是确定性问题，但软件开发本质上是探索性活动。</strong></p>https://imx.ink/tech/2026/04/05/prompt-context-harness-three-shifts/Sun, 05 Apr 2026 17:00:00 +0800https://imx.ink/tech/2026/04/05/prompt-context-harness-three-shifts/<img src="https://f005.backblazeb2.com/file/wml5yw8gwgll/20260505/prompt-context-harness-hero.png" alt="Prompt → Context → Harness 的三级跃迁" style="zoom:50%;" /> <p>最近把一堆关于 Agent / Harness Engineering 的技术分享整理了一遍，发现一个特别清晰的线索——<strong>2023 到 2026 这四年里，AI 工程的&quot;调教对象&quot;发生了三次跃迁</strong>。而且这三次跃迁不是词汇升级，是问题维度的升级。</p> <p>本文记一下这条主线、以及它背后的两个硬事实。</p> <hr> <h2 id="三级跃迁同一张表">三级跃迁：同一张表</h2> <p>这张表最近在很多技术分享里反复出现，基本可以当作行业共识：</p> <table> <thead> <tr> <th></th> <th>2023</th> <th>2024–2025</th> <th>2026</th> </tr> </thead> <tbody> <tr> <td><strong>范式</strong></td> <td>Prompt Engineering</td> <td>Context Engineering</td> <td><strong>Harness Engineering</strong></td> </tr> <tr> <td><strong>在调教什么</strong></td> <td>一句话</td> <td>上下文</td> <td>整个系统</td> </tr> <tr> <td><strong>期望效果</strong></td> <td>模型听话</td> <td>模型懂项目</td> <td><strong>Agent 可控</strong></td> </tr> <tr> <td><strong>可调对象</strong></td> <td>Prompt 文本</td> <td><code>CLAUDE.md</code> / <code>AGENTS.md</code> / <code>SKILL.md</code></td> <td>循环 / 工具 / 权限 / 上下文 / 成本</td> </tr> </tbody> </table> <p>左边的问题是&quot;这句话怎么说更好&quot;，中间的问题是&quot;模型应该看见哪些信息&quot;，右边的问题完全不一样了——</p> <blockquote> <p>整个系统应该怎么运行，才能保证模型在几小时、多轮、多工具、多会话的条件下，仍能稳定交付结果？</p> </blockquote> <p>这不再是对话问题，是<strong>系统工程问题</strong>。</p> <hr> <h2 id="为什么会发生这次跃迁">为什么会发生这次跃迁？</h2> <p>两个硬事实推着它发生。</p> <h3 id="事实一从-l1-chatbot-到-l3-agent单次-token-消耗涨了-100-倍">事实一：从 L1 Chatbot 到 L3 Agent，单次 Token 消耗涨了 100 倍</h3> <p>业界一组被多次引用的数据：</p>