运用迭代方法论让AI交付工业品质的软件
我经常听到一些朋友抱怨说AI写的代码不行，不能用。我认为原因是他们没有正确的采用迭代这个方法论。
迭代是通过多次尝试，不断的逼近一个固定的目标。
在软件开发领域，迭代几乎可以用于所有环节。我们从需求开始。
需求有几个常见的问题:
- 需求本身品质很差，无法理解。比如”给我写个女装电商网站”。
- 需求接收者的理解和发送端的意图不一致。这有可能是因为双方的context不同。
- 需求在变动。比如提出者开始要求”你的软件写完了，给我弄个安卓版，macos版，和Win版，要兼容Windows xp”，在得知成本后，他改成”做个web版算了”。
这几个问题，都可以通过迭代来加以改善。我现在的 Requirements Analyst 角色对一个需求会做一个决策:
-
如果需求本身无厘头，直接判定No further action。比如 A项目的需求填到B项目来了，或者”给我制定一个躺着发财计划”之类的。
-
如果需求明确，则把自己的理解和行动计划总结出来，并且作为comments发到issue管理系统（linear或者github issues）。这个文档会作为后续所有其他角色，developer, troubleshooter, security engineer的行为依据。
-
如果需求有意义但是不明确，则AI提出问题，把单子状态设定”等待澄清”，需求方则通过Issue comment予以解答。这个互动可以迭代多次，每一次都更让双方的理解更为一致。
以上第三条就是典型的迭代逼近，第一第二就是迭代的出口。有了这个流程，我们可以避免很多无效的工作。这个迭代发生于AI和产品经理之间。
但是当我们说需求明确的时候，是作为自然语言使用者这么说。而自然语言的可执行性并不太好。因此，我的Synthetic Engineering team还有一个环节是把需求翻译成测试用例。我的Analyst负责这个工作。 Analyst写完测试用例代码后，直接提交一个PR，人类程序员负责review，重点关注代码形式的测试用例是否和自然语言表达的需求相一致。如果不一致，则把状态置为Testcases Refining，并提出意见。之后AI Analyst根据意见予以修改。
这个迭代发生于AI和人类开发者之间。
在测试用例确定后，AI角色Developer开始工作。他的任务非常明确: 通过测试用例。我的实际经验，即使在熟悉的项目中，第一次implementation能通过测试的概率非常低，总是会有这样那样的问题。这个时候，troubleshooter就入场，通过分析测试用例，修改的代码，和错误信息，给出自己的修改意见，记录在troubleshooting.md中。然后developer根据改文档去修复。 这个互动可以进行好几次。
这个迭代发生于AI和AI之间。目前，我尽量不让人类介入，但是后面也可能加上。
总而言之，AI不是阿拉丁神灯，你不能光凭一句咒语就让你美梦成真。把 AI 视作和人类一样聪明，博学，急躁，有时候偷懒的同事，更为准确。组织起这么一批AI开发软件，和组织人类工程师开发软件一样，需要有良好的软件工程方法。
相关文章
Agent 管理学：AI Coding 的确定性边界
过去一年，我们在 Agent 管理学论坛里和上百位开发者一起踩坑、复盘、迭代。这篇文章是阶段性总结：AI Coding 不是一个技术问题，而是一个管理问题。从需求端、执行端到验收端，在每一段建立明确的契约，就是 AI Coding 的确定性边界。
痛定思痛，AI Agent 给我的教训
从赔付率异动分析项目中总结AI Agent在企业落地的教训：规划阶段LLM不可控、执行阶段数据模拟、表达阶段事实丢失，以及prompt二义性和小概率表现的深层反思。
如何确保AI软件工程品质？
Agents 特区社区邀请19位AI编程先行者参与线上圆桌研讨。与会者来自券商、医疗器械、K12教培、支付宝、开源基础设施等背景迥异的领域。本文探讨概率性系统如何通过确定性约束和独立性验证确保AI代码品质。