AI 时代,重新理解软件工程

这周，我们围绕 AI 研发做了些培训，也重新梳理了我们对软件工程的理解。

当 AI 能够阅读项目、修改代码、运行测试，越来越多的实现工作可以交给它。随之而来的问题是：需求怎样说清楚，项目知识怎样保持一致，生成的结果怎样验证，出了问题又怎样改进？

我们的判断是：AI 正在改变软件工程各个环节的成本，也在扩大我们需要管理的工程资产。需求、知识、工作规则和评测，都要跟着代码一起维护。

这些东西过去就存在。变化在于，它们越来越多地被 Agent 直接用于生成方案、修改代码和判断任务是否完成。一处业务口径过期，就可能影响后面的实现和测试。它们的变更同样需要评审和验证。

代码生成变快，工程瓶颈也在移动

假设一个功能的实现只需要很短的时间，需求却来回解释了几轮，代码完成后又长时间等人评审，最后因为业务口径理解错了重新做一遍。这时，继续提高代码生成速度，对交付的帮助就有限了。

我们更关心一项任务从提出到上线，总共花了多少时间，其中多少在等待，多少在返工。模型调用、运行环境、人工验证和后续维护，也都要计入成本。

同时启动多个 Agent，可以增加代码产出；如果提交都堆在评审队列里，交付仍然会停在那里。这时需要解决的是评审怎样分工、哪些检查可以自动完成。

一次迭代结束，我们更愿意对照三件事：交付周期有没有缩短，返工有没有减少，上线后有没有增加故障。

需求和知识也要按工程资产维护

以前，一份需求写得不完整，熟悉业务的同事可能会凭经验补上，或者转身找人问一句。

Agent 也可以追问和查资料，但它需要知道去哪里找、哪一份可信、遇到冲突该听谁的。否则，一个看起来合理的猜测就可能进入方案、代码和测试。

我们认为，需求表达应该更重视可验证的行为。比如“支持导出报表”，还需要说清楚导出哪些数据、按什么口径计算、不同角色能看到什么、没有数据时如何处理。技术方案可以继续讨论，这些业务含义要先对齐。

需求里还应该允许出现“这件事没有想清楚”。把疑问留在明面上，后续才知道哪些地方需要判断。过早写成一份面面俱到的文档，容易把假设包装成已经确定的要求。

某个接口为什么保留旧行为，一项指标为什么采用这个算法，之前为什么放弃另一种方案——这些信息如果只存在于某个人的记忆里，每换一个执行者，就可能重新走一遍弯路。

当几个 Agent 依据同一份旧资料分别编写代码和测试时，它们甚至可能对同一个错误理解达成一致。实现与测试相互吻合，业务含义却已经错了。关键业务口径仍需要由懂业务的人确认。

沿用报表的例子，一项统计口径调整以后，需求说明、指标定义、计算实现和验收用例都需要检查。只更新其中一处，下一个 Agent 就可能依据旧口径继续工作。

把它们当作工程资产，意味着相关内容要能随变更一起更新，也能追溯到一次具体交付。 看到一份已上线的报表，我们应该能找到它采用的业务口径、对应的实现，以及当时用什么结果验收。

重要决定留下原因，业务规则标明负责人和更新时间，被替代的结论标明状态。下一次改动时，人和 Agent 才能分清哪些仍然有效。

一次统计口径变更，需要关联检查业务依据、实现、工作规则和评测记录

把有效的做法放进工作流程

比如提交代码前，要说明改动目的、关联任务和验证结果。这套做法可以整理成一个可复用的技能（Skill），每次提交时调用，省去反复交代。

其中能够自动判定的要求，再接入检查程序。提交没有关联任务，可以提示补充；要求通过的测试失败，就阻止合并。

“记得跑测试”写进规则，只能告诉 Agent 应该做什么。检查还需要确认测试是否执行、结果是否有效；合并条件由设置了相应权限的服务端流程把关。

检查深度按改动范围和失败代价确定。比如修改报表标题，可以只检查展示效果；修改统计口径，就需要业务负责人确认含义，并核对计算结果。只用于试想法的原型，也没有必要一开始就承担生产系统的全部流程。

技能和规则本身也需要维护。改了提交检查的方法，要验证原来容易遗漏的事情是否仍然能被发现；换了 Agent，要重新检查这套方法是否适用。重要改动留下版本和原因，发现效果变差时，才有依据定位和恢复。

同时要精简已经过时或不适用的规则。检查很少报错，本身不能说明它无效；应该看它防范的问题是否仍然存在。规则增加和删除，都要有具体理由。

验收要能证明结果可靠

培训材料里有一个教学例子。用户问“华东区的销售额是多少”，Agent 生成的查询漏掉了地区筛选。恰好测试数据里只有华东记录，最后的数字仍然正确。

只看这一个答案，问题就被放过去了。加入其他地区的数据以后，错误才会显现。

因此，除了比对最终数字，还要检查地区、时间等查询条件。测试数据也要放入其他地区的记录，才能识别漏筛选的问题。

教学示例：加入华南数据后，漏掉地区筛选的错误暴露出来，图中数字均为虚构

这里要区分 AI 参与开发，以及 AI 本身构成产品功能两种情况。前者需要继续验证接口、权限、边界条件和集成行为；后者还需要观察 Agent 的实际表现。

用户换一种问法，它是否仍然理解同一个意思？追问一句“那上个月呢”，它是否保留了正确的地区和指标？工具调用失败时，它是否如实说明情况？

模型、提示词、工具或知识发生变化，都可能影响这些表现。即使业务代码没有修改，相关场景也需要重新验证。

评测可以从真实失败和关键业务场景开始：数值和状态交给程序检查；表达质量先写清评分标准，再结合 AI 评判与人工校准。对存在波动的场景，多次运行，观察结果是否稳定。

用例全部通过，仍然不能代替上线后的观察。真实用户总会带来测试里没有覆盖的情况。

发现一次问题，就把能复现它的输入、数据和预期结果补进用例。下一次换模型、改提示词、调整工具时，再跑一遍。

评测集需要像代码一样维护。业务规则变了，标准答案也要更新；某项能力已经稳定，就把它留在回归检查里。

每次评测还应记录所用的模型、提示词或技能版本、测试数据和判定标准。表现发生变化时，我们才有机会分清是实现退步了、模型行为变了，还是业务标准已经调整。

重新理解工程师的价值

回到报表这个例子，Agent 可以生成查询和页面。工程师仍然要判断：表与表是什么关系，关联以后会不会重复累计，旧接口的使用方会不会受影响，出错后怎样定位和恢复。

这些判断依赖对业务、数据和代码的理解。我们会更看重一个人能否发现方案中的问题、解释取舍，以及用测试证明关键行为符合要求。

分工也可以围绕这项改动展开：产品确认统计口径，测试设计能暴露漏筛选和重复累计的数据，开发检查实现，运维确认发布与恢复方式。Agent 可以参与各个环节，负责的人要知道该检查什么。

我们建议先选一项真实需求走完这个过程。需求说不清，就补业务说明；同一个问题反复解释，就整理共享规则；错误靠人碰巧发现，就补一条能够复现它的测试。

每完成一项工作，都应该留下点能继续使用的东西：更准确的业务说明、一段经过验证的方法、一个能发现旧问题的测试。

这些积累要跟着项目留下来，也要随着业务、模型和工具的变化继续更新。下一次修改时，团队能找到当时的业务依据，复用有效的做法，并验证这次改动有没有破坏原有能力。