AI驱动的软件工程（下）：AI辅助的质检与交付

📚 系列文章导航
AI驱动的软件工程（上）：人机协同的设计与建模
AI驱动的软件工程（中）：文档驱动的编码与执行
AI驱动的软件工程（下）：AI辅助的质检与交付

大家好，我是阿威。

在系列的前两篇文章中，我们走过了一段激动人心的旅程。首先，我们作为“架构师”，通过结构化的三阶段设计流程，引导AI将一个模糊的想法，转化为了一套完整的工程蓝图。接着，我们化身“项目经理”，通过AIDC这套文档驱动的开发方法论，成功地让AI像一个遵守纪律的工程师一样，将蓝图一行行地变成了真实的代码。

至此，我们的项目代码库已经初具规模，git log里充满了AI自己生成的、格式规范的提交记录。自动化检查工具也告诉我们，代码风格良好，没有低级的语法错误。

一个尖锐的问题摆在了面前：代码存在，就等于项目完工了吗？

答案显然是否定的。静态检查无法保证业务逻辑的正确性。单元测试（即使有）也难以覆盖所有集成场景。代码在AI的“模拟环境”（它的上下文中）里是正确的，但在我这台真实的、有着复杂环境依赖的机器上，能顺利运行吗？

这就是我们收官之篇要解决的核心问题：如何对一个主要由AI构建的项目，进行最终的、可靠的“终局质检”？

事实证明，直接让人类从头到尾审查AI的全部代码，是极其低效且不现实的。我们必须设计一套全新的、依然以AI为核心执行者，但由人类掌握最终控制权的协同工作流。在这个阶段，我们的角色将再次发生转变，上演一出人机协同的“终局之战”。

终局之战中的角色再定位

在编码完成后的这个新阶段，人与AI的角色分工需要重新定义，以确保最高的效率和绝对的安全。

AI的角色：转型为分析师、建议者和配对伙伴。它的核心任务，是通过静态分析深度扫描代码库，找出逻辑上、结构上的潜在问题，并提出精准的代码修复建议。最关键的一点是：在这个阶段，AI不直接操作我的执行环境。它不运行任何pip install，也不启动任何服务。
我的角色：成为执行者、验证者和最终决策者。我负责执行所有AI建议的终端命令，在我的本地或测试环境中部署服务，亲眼验证服务的状态，并对AI提出的每一处代码变更进行审查和批准。我，是接触真实环境的唯一一人。

这种角色划分，完美地利用了双方的优势：AI拥有无与倫比的分析速度和广度，能快速发现隐藏在代码角落里的问题；而人类则掌握着对真实环境的最终控制权和验证能力，确保了项目的安全性和最终交付质量。

这套后协同工作流，我将其划分为四个主要阶段，它将带领我们从静态的代码，走向一个经过完整验证、可随时交付的“准产品”。

四阶段质检：从静态分析到运行时验证

阶段一：静态分析与代码完整性检查 (AI主导)

这是我们质检流程的第一步，我称之为对AI代码的“全面体检”。目标是在不运行项目任何一行代码的前提下，通过AI强大的静态分析能力，识别出所有潜在的代码级问题。

我会给AI下达一个高级指令：

“现在，请对整个AgentWeaver代码库进行一次完整的静态分析和完整性检查。你需要完成以下任务，并最终汇总成一个TODO任务列表：

代码调用可达性分析：检查所有函数和方法的调用关系，找出所有参数不匹配、方法未实现、模块导入错误等硬伤。
依赖与配置分析：检查requirements.txt，分析是否存在版本冲突或不兼容问题。检查所有配置文件，确保其完整性和一致性。
代码规范复查：再次模拟运行black和ruff，找出任何在开发过程中可能遗漏的格式问题。”

AI接到指令后，会像一个资深的静态代码分析工具一样，开始它的工作。

在可达性分析中，它可能会发现一个API路由函数调用了一个需要传入3个参数的服务层方法，但只传入了2个。或者，一个类继承了某个抽象基类，却没有实现其中一个必须实现的方法。这些都是自动化Linter很难发现的、深层次的逻辑错误。
在依赖分析中，它可能会发现requirements.txt中某个库的版本过低，与另一个库产生了不兼容。或者提醒我.env.template中定义了一个数据库密码，但在任何配置文件中都未被使用。
在规范复查后，它会把所有分析产出的问题，汇总成一个结构化的、清晰可执行的TODO任务列表。

例如：

[ ] [Bug] api/routes.py:56: create_agent函数调用services.agent.create时缺少user_id参数。
[ ] [Refactor] core/workflow.py: WorkflowEngine类未实现抽象基类Runnable的get_status方法。
[ ] [Chore] requirements.txt: fastapi版本(0.95.0)与pydantic版本(2.1.0)存在已知的兼容性问题，建议将fastapi升级到0.103.0以上。
[ ] [Style] utils/parser.py: 文件末尾缺少空行。

这份清单，就是我们进入下一阶段的“作战地图”。

阶段二：协同代码修复 (人机结对)

这个阶段，我们进入了一种高效的“人机结对编程”模式。我们的目标，是根据上一阶段生成的TODO列表，逐一修复所有问题。

这个循环非常简单、高效：

AI选择任务：AI从TODO列表中选择优先级最高的任务，并标记为“进行中”。
AI生成修复代码：针对该问题，AI使用edit_file工具，生成一个最小化的、精确的代码变更。它不会返回整个文件，而只会提供需要修改的那几行以及足够的上下文。
我审查并批准：我作为人类开发者，审查AI提出的代码变更。确认这个修改是正确的、无害的之后，我批准应用该变更。
我本地验证：对于一些风格问题，我会在本地运行black .和ruff --fix来确保修复后代码的规范性。
循环：AI将已完成的任务在TODO列表中标记为“已完成”，然后继续处理下一个任务。

这个过程会一直持续，直到TODO列表中的所有问题都被清空。这种模式避免了我亲自去定位和修改这些琐碎但重要的问题，极大地提升了修复效率。

阶段三：运行时环境验证 (人类主导, AI辅助)

当所有静态问题都被修复后，代码在“理论上”已经变得更加健壮。但理论必须接受实践的检验。现在，是时候“点火”了。

在这个阶段，控制权完全转移到我的手中，AI的角色变成了我的“远程技术支持”。

环境设置 (AI指导，我执行)：
- AI会提供清晰、分步的环境设置指令，就像一份部署手册。例如：“请首先创建一个Python 3.10的虚拟环境。然后，请执行pip install -r requirements.txt来安装所有依赖。”
- 我，是那个在终端里按下回车键的人。我会严格按照它的指令执行。
错误处理与调试 (我报告，AI分析)：
- 这是最能体现人机协作价值的环节。在执行pip install时，我可能会遇到某个依赖包（比如bcrypt）因为缺少系统库而编译失败。或者在启动应用时，我看到一个数据库连接超时的报错。
- 我的任务，是将终端中完整的、未经删改的错误日志，原封不动地反馈给AI。
- AI的任务，是分析这段通常很长、充满技术术语的错误日志，并定位问题的根源。它可能会告诉我：“这个gcc编译错误表明你的系统中缺少C语言编译器和Python的开发头文件。在Debian/Ubuntu系统上，请执行sudo apt-get install build-essential python3-dev来解决。”或者“这个数据库连接错误，请检查你的.env文件中的DB_HOST和DB_PORT是否正确配置，并确认你的数据库Docker容器正在运行中。”
- AI提供具体的解决方案，甚至修复代码，我来执行和验证。这个过程极大地缩短了环境问题的排查时间。
服务初始化与健康检查 (AI指导，我验证)：
- 当环境配置完成，应用成功启动后，AI会继续指导我进行数据初始化等操作。例如：“请执行python -m db_models.manage init-db来初始化数据库表结构。”
- 我会执行命令，并将结果反馈给它。最后，AI会让我调用应用的健康检查API（如/health），并让我将返回的JSON结果告诉它，以确认所有核心服务（数据库、缓存、AI模型服务等）都已正常连接。

当健康检查通过时，我们就可以满怀信心地说：这个由AI编写的项目，在真实的运行环境中，活了过来。

阶段四：最终化与文档更新 (AI主导)

在所有代码修复和环境验证都完成后，我们进入最后的收尾工作。

代码提交 (AI生成信息，我执行)：
- AI会基于本次质检的所有工作，生成一条清晰、规范、信息量丰富的Git提交信息。例如：fix(all): 完成交付前完整性检查与运行时验证，并在详细描述中列出修复的主要问题。
- 我来执行git add .和git commit，完成这最后一次、也是最重要的一次提交。
文档更新 (AI的最后一项任务)：
- AI负责更新项目的“外部记忆”，以反映项目的最终状态。它会自动修改README.md，更新其中的安装和运行指南；它会更新开发日志.md，记录本次质检的完成；它还会将项目开发计划.md中的所有任务状态都更新为“已交付”。
- 我最后一次审查这些文档的准确性和完整性。