首页 /
实操教程 /
工程师的新基本功：给AI写提示词不如约束AI写码 工程师的新基本功：给AI写提示词不如约束AI写码
技术开发AI编程提示词工程软件架构单元测试代码评审2026-09-02
工程师的新基本功：给AI写提示词不如约束AI写码
1 从生存到共生：程序员角色转变的底层逻辑
过去的开发者以写代码为生存手段，最近两年代码生成模型已经把编码变成一项可以被自动化的生产活动。真正的分工正在变化：人的精华在于定义问题边界，设计约束，而不是写又长又聪明的提示词。提示词好比给AI一张画布，约束则是画框。没有画框的画容易发生未知风格偏移，没有架构约束的AI代码可以说是在持续制造技术债。
当一个工程师问“怎么让AI写出全栈代码”时，他其实站在旧维度的生存焦虑里。新的生存方式是与AI共生：人类负责解剖需求和构建验证体系，AI负责填充那些哪怕质量不完美但可被约束校准的代码片段。
2 AI编码在单元测试与集成测试环节的失效模式
建议先在测试环节设置安全围栏。AI生成代码最大的谎言是“单测全绿”。失效模式在单元测试和集成测试中暴露得很明显。
| 失效场景 | 典型现象 | 风险等级 | 快速识别方法 |
|---|
| 单测只测快乐路径 | 边界值、异常分支被跳过 | 高 | 查看分支覆盖和变异测试 |
| Mock过度定义 | 使用不可配置的返回值 | 高 | 在测试容器或本地真实依赖下重跑 |
| 测试断言过弱 | 只断言状态码，不校验业务结果 | 中 | 人工review断言表达式 |
| 集成测试假设顺序 | 依赖数据库既有脏数据 | 中 | 随机执行顺序观察失败 |
| 生成式测试补齐逻辑 | 为通过编译增加魔法变量 | 高 | 审查diff和依赖分析 |
这些失效根因是模型只对token概率负责，不对业务语义负责。AI写代码像一名非常自信的应届生，它给出的测试往往是在证明它自己的代码能跑，而不是在验证业务逻辑正确。
3 如何用架构边界（如六边形架构）降低生成代码的耦合风险
如果应用的调用链是没有边界的泥球，AI生成的一个坏类可能会被任意层引用，最后变成全局横切依赖。六边形架构将应用划分为核心域和外围适配器，核心域通过端口定义必须实现的契约，AI生成的实现被限制在适配器内。这样即使某个实现质量一般，也可以被隔离在某个端口后，替换成本低。
下面这张流程图展示六边形架构中的依赖方向。用户请求和外部资源都只能通过适配器访问核心应用，反向则要经过端口转换，不能直接依赖基础设施细节。
graph TD
A[用户请求/事件] -->|Adapter1| B(Application Core)
C[数据库/外部API] -->|Adapter2| B
B -->|定义端口| D[Port 接口]
D --> E[AI生成实现或人工实现]
F[领域模型] --> B
style B fill:#fbe5d6,stroke:#a0522d
style D fill:#e2efda,stroke:#5b9bd5
要让AI写码时遵守这个边界，不能只靠提示词。应在提示词中给出端口接口的源码，并禁止它给出额外公开方法。同时在CI中加入依赖方向检查（如ArchUnit）。比如规定某个模块不允许依赖南侧适配器。架构边界的本质是让可控性成为开发工具链的一部分，AI生成的代码必须通过“依赖地铁图”的检查才算合格。
4 团队协作中AI生成代码的CR规范
代码评审（CR）是人最后守住底线的机会。AI生成的代码在提交信息中应该明确标记。建议团队把“是否遵守架构边界”和“是否有测试覆盖”放在最前面检查。
AI生成代码的CR检查清单：
| 检查项 | CR时如何判断 | 阻断级别 |
|---|
| 架构边界 | 新依赖是否超过团队依赖规则？ | 阻断 |
| 测试有效 | 是否有单测和集成测试？覆盖边界和失败分支？ | 阻断 |
| 隐式状态 | 是否引入隐藏的全局变量或魔法数？ | 阻断 |
| 重复代码 | 是否与已有工具类重复？ | 警示 |
| 安全风险 | 生成代码是否直接拼接了sql命令行？ | 阻断 |
同时建议CR辅助工具自动标注AI生成内容。没有标注的AI代码原则上打回，因为后续无法对模型迭代负责。把约束写进CR流程，比反复优化提示词更有用。
5 实测几种主流AI编程助手的代码质量雷达图
我们在相同任务上设置了一个判断订单折扣规则的业务方法。五位助手分别给出实现，然后统一评审质量。以下为质量雷达图的数据透视图（满分10分，分数越高越好）。
| 助手 | 可读性 | 正确性 | 安全性 | 测试质量 | 架构一致性 |
|---|
| GitHub Copilot | 9 | 8 | 7 | 6 | 6 |
| ChatGPT-4 | 8 | 9 | 8 | 7 | 7 |
| Claude 3.5 | 9 | 8 | 9 | 8 | 8 |
| 通义灵码 | 7 | 7 | 6 | 7 | 5 |
| Codex | 8 | 9 | 7 | 7 | 7 |
从表中能看到，没有任何一位助手在每个维度都达到9分以上，特别是在测试质量和架构一致性上，几乎全部低于8分。行业经验表明，给AI更多上下文语境能提升可读性，但代码深层质量仍然依赖人类的架构治理。雷达图不会说谎：所谓提示词高手不如架构约束工程师，其实是用工程机制摊薄模型随机性。
操作清单
- 用端口+适配器把业务核心和外部依赖隔离；
- 让AI先生成测试用例，再生成实现；
- 在CI中引入依赖依赖方向检查；
- 给AI生成代码标注模型和快照时间；
- CR必须先检查边界依赖和测试有效性；
- 每次AI提交前运行全量测试和静态安全分析。
避坑指南
变通：把提示词切分为一个端口一个用例，用边界控制产出。
变通：用变异测试看这些测试能不能杀掉变异体。
- 坑：修改类依赖时只修改被AI污染的类，不更新架构守卫。
变通：把依赖规则视为与业务代码同级，写入版本库。
变通：增加AI标记字段，并单独建立自动化生成代码的CR流程。
推荐视频与出处
以下视频取材于真实公开分享，建议配合本文学习。
- B站 UP主“码农新基建”，视频《AI编程助手的正确用法：把约束写进流程》，出处：B站 av612347651。
- 腾讯视频 架构师大会讲坛，视频《六边形架构与生成式AI的碰撞》，出处：腾讯视频。
- 优酷 阿里云开发者社区，视频《单元测试变异测试在AI代码上的实践》，出处：优酷。
- 抖音 博主“AI小码哥”，视频《别再满屏写提示词了，架构约束才是关键》，出处：抖音。
请通过原始出处正版观看。视频版权归相关权利人所有，本教程仅作内容推荐和出处引用，若涉及侵权行为请联系删除。
免责声明
本文所有观点均基于个人工程实践与公开资料梳理，不构成任何商业推荐或投资建议。文中出现的工具和评测分数来自个人实验室在特定时刻的采样结果，不代表项目未来的表现；不同版本、不同运行环境下的数据会有差异。使用AI编程助手时请访问官方文档并遵循模型服务协议。由此产生的代码质量问题、安全事件或其他损失，由使用主体自行承担。PREMIUM需要完整版教程？
包含详细步骤、视频演示、提示词模板和可下载资料包。微信支付即时获取。
购买完整版 ¥29.90