AI写更多代码，工程师仍需负责系统设计

软件工程 · AI 辅助开发

持久的决策、相关的上下文、可验证的增量：在 AI 辅助开发中保留工程判断力的务实视角。

当人们说 AI 已经改变了软件开发时，我想知道他们指的是哪一部分。是产出实现？是探索设计？还是判断一个系统是否解决了正确的问题？

这些活动彼此关联，但自动化其中一项并不意味着其他几项也随之解决。我的观点是：agent 可以承担更多实现工作，并在分析、设计和测试中提供协助，而工程师仍然负责决定要构建什么，以及什么样的证据足以接受它。

这改变了工作方式，但并不会让责任消失。

我对“取代写代码的人”这种说法持谨慎态度。它把开发者简化为打字，低估了 agent 能够协助的范围，并把任务自动化变成了一种关于岗位的主张。关于劳动力替代的主张，需要超出一次令人印象深刻的演示之外的证据。

更让我感兴趣的是一个实际问题：我们如何在使用这些工具的同时，让决策保持可见、让反馈保持有用？

对话对于探索选项很方便，但把架构决策的唯一记录放在对话里是很脆弱的。

模型的上下文是有限的。一次长会话可能被摘要、压缩，或者带着部分信息被恢复。摘要可以保留结论，却丢失让这个结论变得合理的条件。“使用本地缓存”和“使用本地缓存，因为这个屏幕必须在无网络连接时仍然可用”是不同的。

Anthropic 对长时间运行的 agent 的描述提到了跨上下文窗口的连续性问题，以及一种使用增量工作和持久化进度产物的方法。它还报告说，压缩可能留下不清晰的指令。这是一份关于特定设置的厂商工程报告，而不是对开发工作流的普遍比较。

我的偏好是给持久决策一个小而可审查的归宿。一个 PROJECT_GUIDE.md 可以包含：

文件名本身没有特殊魔力。agent 不一定会自动加载它。我会通过工具支持的项目指令把它连接起来，或者在任务中明确包含它，然后检查 agent 的理解。

对于每个增量，我会提供相关文件，并要求简要说明预期变更、约束和验收用例。复述是及早发现误解的机会；实现仍然必须证明其符合要求。

Simon Willison 在 2025 年 6 月关于上下文工程的讨论有助于框定“为下一步模型选择信息”这个问题。我更窄的建议是：让这种选择是有意为之的，并检查其后果。

仅靠 Markdown 既不能保证检索，也不能保证服从。在每个任务中发送所有文档会增加上下文和成本。选择性检索可能减少输入，但维护文档、检索文档和纠正错误也会消耗资源。任何关于节省的说法都需要对完整任务进行测量。

考虑一个假设的移动端搜索屏幕。这是一个示例说明，不是已完成项目的报告。

用户故事可以是：“作为用户，我想搜索已保存的项目，这样我就能找到某个项目，而不必滚动整个集合。”对于第一个增量，范围是对现有项目的本地搜索。远程搜索和对持久化的更改不在范围内。

在实现之前，我会明确这些验收用例：

这些用例暴露了一个技术问题：过滤到底是否需要异步工作？agent 可以帮助评估这个决策。我们应该根据预期的数据大小和响应性要求来解决它，而不是因为某个模板期望并发就引入并发。

对于这个例子，我可能会选择单向数据流、显式 UI 状态，以及过滤逻辑与渲染的分离。这使状态转换更容易检查。另一个系统可能有理由采用不同的结构；这是一个有目的的工程选择。

项目指南应该保留这个目的。功能级别的笔记应该解释行为以及任何新决策。它们不需要复述整个架构。

在增量之后，我会检查 diff、运行相关检查，并实际操作屏幕。如果 agent 无视范围限制重写了持久化，即使测试通过，这种扩展也不可接受。如果空状态看起来正确，但搜索匹配了错误的字段，截图也无法证明正确性。

agent 的输出是概率性的。验收应该依赖于我们能够检查、并且在可行时能够复现的证据。

一个本地验证命令可以运行格式检查、静态分析、编译和聚焦测试。这些检查回答不同的问题。格式化工具检查约定；编译器检查语言和类型规则；测试在选定条件下评估选定的行为。它们都不能证明我们选择了正确的产品行为。

受控的验证也需要受控的输入。工具版本、fixture 和执行条件都很重要。涉及计时、设备、网络或外部服务的测试可能不稳定。把测试套件称为确定性的，并不会让它真的变成确定性的。

即使是一个完全可重复的检查，也可能验证错误的东西。一个搜索测试可能断言某个结果出现，却没有检查是哪个结果。生成的测试可能忠实地编码了与生成的实现相同的误解。我会对照验收用例审查断言，并使用刻意选择的示例，包括一个失败用例。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）