过去一段时间，AI 辅助开发越来越热。但在实际工作中，大家更关心的往往不是“AI 会不会写代码”，而是：在真实项目里，尤其是在 Qt/C++ 这类工程型开发场景里，AI 到底该怎么用，才能真正帮上忙。这篇文章不打算泛泛介绍工具，也不想单纯讨论模型能力，而是想借一个真实项目复盘的机会，讲一讲我们在实践中总结出来的一些方法。

这个项目，是一次联合仿真工具箱从 Windows 迁移到 CentOS 的工程实践。项目中既有已有代码和工程结构，也涉及接口、构建、适配、验证等一整套工作。我们尝试让 AI 参与到这条完整流程中，而不只是用来辅助写几段代码。

回头看，这次实践最值得总结的，并不是 AI 改了多少文件、写了多少代码，而是：在工程项目里，怎样给 AI 提供合适的上下文，怎样拆解任务，怎样建立验证闭环，以及怎样沉淀可复用的经验。

一、复盘的项目：联合仿真工具箱从 Windows 迁移到 CentOS

这次实践的核心案例，是一个典型的复杂工程迁移项目。

项目目标是：
将现有的 Windows 版联合仿真工具箱 迁移到 CentOS 环境中，并尽量保持原有工程结构和核心机制稳定，包括：
● 主控端插件
● 从控端常驻程序
● 模型库
● 相关依赖与构建链路

从工程形态来看，这就是一个非常典型的 Qt/C++ 项目：
● 有已有工程可参考
● 有 SDK、接口说明、用户手册等资料
● 有平台迁移需求
● 有通信机制需要保持一致
● 有部署、编译、验证、测试等完整工程链路

项目结果
根据项目复盘材料，这次实践中最终完成了：
● 32 个模型改动
● 64 个代码文件改动
● 约 8000 行代码修改
● 原本预估 1–2 人月 的工作量，最终大约 1 人周 完成

这个结果最值得关注的，不是“AI 生成了多少行代码”，而是：
AI 参与了复杂 Qt/C++ 工程任务的完整推进，而不只是局部辅助。

二、真正起作用的，不只是模型，而是一套工程化开发范式

这次项目里真正起作用的，不只是模型能力，而是一套更适合工程场景的使用方式。我把它归纳成四步：

第一步：顶层规划（需求分析 + 架构设计）
● 使用通用大模型（例如GPT/Gemini）进行需求梳理、方案对比、架构设计和原型生成
● 明确目标、边界、风险点和验收标准

第二步：任务拆解（Plan模式 + 多Agent协同）
● 利用IDE的Plan模式进行任务拆解，再执行开发
● 将参考代码、设计文档、接口说明放入项目目录
● 复杂任务可分配给不同 Agent 协同处理
● 开发与测试角色尽量分离，避免自检遗漏

第三步：闭环开发（自动编码 + Skill复用 + 自动测试 + 阶段提交）
● 让 AI 按“开发 → 自测 → 修复 → 再验证”的闭环持续迭代
● 高频重复操作沉淀为 Skill，提升后续效率
● 能自动验证的任务尽量自动完成，减少返工
● 阶段性代码及时提交到 GitLab / SVN 做版本留痕

第四步：持续演进（错误总结 + 知识沉淀）
● 将已解决问题、常见坑点、关键命令沉淀到长期记忆文件
● 持续维护项目知识库，降低重复犯错概率
● 让经验复用成为下一轮开发的输入

三、这个项目是怎么推进的

如果把这次实践还原成更具体的工程动作，大致可以分成以下几个步骤。

第一步：准备完整参考资料，让 AI 先理解上下文
AI 在复杂工程里能不能发挥作用，很大程度上取决于你给它的上下文是否完整。
这次实践中，项目目录中准备了比较完整的参考材料，包括：
● Windows 版工程源码
● 用户手册
● 接口说明
● SDK 头文件
● 相关代码和示例
● 测试工程或验证样例
这一阶段本质上不是在“让 AI 开发”，而是在建立任务上下文。

第二步：先输出开发计划，再进入执行阶段
第二步不是直接开工，而是让 AI 先输出开发计划。
这份计划至少应该包括：
● 任务拆解
● 执行顺序
● 验证方式
● 自动验证项
● 人工确认项
这一步非常像项目经理在做的工作。
但 AI 在这种结构化规划任务上，其实非常高效。

第三步：利用多Agent，按不同角色去推进执行
在复杂工程里，一个很有效的做法是设定多个不同视角和角色的Agent，进行协作开发，例如本项目分了三个角色的Agent：
● 项目管理角色：负责边界控制、阶段跟踪、任务汇总
● 开发角色：负责代码实现、构建修改、问题修复
● 测试角色：负责独立验证、补测试、找遗漏
虽然底层还是 AI，但从工作方式上做角色分工，会明显减少“自己觉得自己已经完成”的误判。
因为开发视角和测试视角天然不一样。一个角色认为没问题的内容，换一个角色检查时，往往更容易发现遗漏。

第四步：把高频动作沉淀成可复用能力
项目推进过程中，有很多动作会不断重复，比如：
● 虚拟机自动编译
● 利用QTest进行单元测试
● 自动运行modelica模型并对比windows和centos的运行结果
这类动作如果每次都重新描述，效率会比较低。
所以更好的方式，是尽量把它们沉淀成可复用能力，方便后续继续使用。

四、 几点实践经验

1.开发策略
● 先用起来：多用、多踩坑、多复盘，在真实项目里使用会倒逼你想办法优化使用方法。
● 让AI跑长流程：深夜、周末时段可以配置好闭环开发流程，让 AI 长时间持续推进。
● PyQt开发界面：AI对Python / PyQt 通常更熟和能力强于C++，可以选择PyQt来开发界面。
● 新模型通常更省总成本：不要只盯单价，老模型虽然便宜，但返工次数、Bug 数量、沟通轮次可能更多。
● 模型强度按阶段分配：
○ Plan 模式、架构设计、复杂 Debug：用最强模型 + 更高思考强度（例如opus4.7 max/codex5.3 超高）；
○ 实际开发、常规修复、小步迭代：可降到中等模型或中等思考强度（sonnect 4.6 medium/codex 5.3 中）

2.Prompt经验

● 尽量使用正向、明确、可执行的指令：多说“请做什么”，少说“不要做什么”。与其说“不要改错”，不如说“请将旧代码移动到注释区域，并保留原逻辑”
● 陷入死循环时进行“重置”：当 AI 在错误路径里反复打转时，不要一直局部修补，直接输入：“基于你当前掌握的所有信息，废弃现有xxx方案，重新实现一个更好的版本。”
● 让AI作为方案的审核人：切换角色让AI作为审核人的角色，例如“你作为审核者，请你提出问题质疑我，让我回答，直到通过审核”

3.QT C++项目基础配置
● 同元AI驱动C++/QT开发实践：打造全自主研发工作流
4.多 Agent 协同
● 组建团队示例：项目管理+ 测试+ 开发。
● 开启IDE的全部权限，让AI进行长时间开发，
● 避免人工干预多 Agent 协作细节，让 AI 自主协调，防止人为干扰导致的额外错误。
● 开发 Agent 有时会误判某些功能“已经开发完成”，但让测试 Agent检测或换一个大模型，往往更容易发现遗漏。

五、结语

这次项目带给我们的启发，不只是完成了一次迁移任务，更是让我们对 AI 辅助工程开发有了更具体的认识。对 Qt/C++ 团队来说，把 AI 用进真实流程里，比单纯把它当成问答工具更重要。