什么交给 AI，什么自己扛：程序员的责任边界

AI 可以提速，但不能替代判断。AI 负责"快"，人负责"对"。

AI 负责"快"，人负责"对"。AI 做可标准化、可重复、出错成本低的部分；人做需要判断、权衡、承担责任的部分。AI 生成的每一行代码，都必须有人愿意为它负责。

完整分工总表

阶段	AI 做	人做
需求	文档初稿、竞品分析	价值判断、优先级、验收标准
设计	架构图初稿、方案对比	架构决策、权衡、ADR
开发	脚手架、样板、CRUD	关键路径、业务逻辑、安全
测试	用例生成、脚本	测试策略、充分性判断
数据合规	清单初稿	合规判断、法律审查
安全	扫描、规则生成	方案设计、逐行 review
性能	压测脚本、分析初稿	SLA、调优、容量规划
运维	监控配置、告警规则	SLO、应急、稳定性
发布	脚本、检查清单	发布决策、回滚负责
团队	规范初稿、CI 配置	流程、协作、知识沉淀
成本	估算初稿	预算、ROI
伦理版权	风险提示	合规判断、法律责任
AI 风险	---	验证、审查、不盲信
度量	数据收集	指标定义、持续改进

五条铁律

AI 是生成者，不是责任人。 谁 Merge、谁上线，谁负责。
Review 不是走过场。 看不懂的代码，不该进主干。
AI 生成比例越高，Review 越严。
责任不能外包给 AI。 出事不能甩锅"AI 写的"。
最终检验：你敢不敢为这段代码负责？ 敢，就用；不敢，就自己写。

三条原则

AI 提速的是"执行"，不是"决策"。
判断力是工程师最稀缺的资源，不能外包。
AI 放大的是人的能力，不是弥补人的短板。

结语

拥抱 AI，是为了从繁琐中抽身，去思考更宏大的架构、更严谨的逻辑、更核心的业务。不要让工具剥夺你的判断力------那才是工程师真正的立身之本。

以下为详细说明

一、需求与产品阶段：先想清楚"做什么、为什么"

项目成败往往在写代码之前就已决定。AI 可以帮你写需求文档，但判断需求价值、拍板优先级，只能由人来做。

AI 能做：

需求文档初稿、用户故事拆分
竞品分析、市场调研整理
验收标准初稿

人必须做：

判断需求真伪：这个需求该不该做？
拍板优先级：先做哪个、后做哪个？
定义验收标准：怎么算做完了？
产品设计：交互、流程、边界

边界： AI 可以列方案，但不能替你做"做不做"的决定。

二、AI 做：适合交给机器的"体力活"

AI 的优势在于模式识别和海量语料记忆。那些高度标准化、重复性高、出错成本低的任务，是 AI 的最佳舞台。

1. 脚手架（项目初始化）

具体指什么：

项目的目录结构搭建、依赖管理、构建配置（如 pom.xml、build.gradle、tsconfig.json）、基础框架模板（Spring Boot / React / Vue），以及数据库连接、Redis、日志等基础中间件的接入代码。

为什么适合 AI：

这些内容在全网有无数公开且成熟的模板，属于纯粹的"填空题"，AI 生成的质量非常稳定。

注意边界：

版本兼容性必须由人工确认
不要盲目接受 AI 塞进来的多余依赖包
涉及密钥管理等安全配置，绝不能直接照搬 AI 的默认输出

2. 样板代码（Boilerplate）

具体指什么：

DTO / VO / Entity 之间的相互转换、Controller / Service / Mapper 的基础骨架、前端组件的 Props 和类型定义、单元测试的 setup / teardown 流程。

为什么适合 AI：

样板代码的特征就是"不得不写，但毫无创造性"，模式固定，AI 几秒钟就能生成几百行。

注意边界：

命名必须符合团队的代码规范
不要为了省事过度生成导致代码膨胀
生成的样板代码必须是人类能看懂、能 review 的

3. CRUD（增删改查）

具体指什么：

单表的增删改查、分页、排序、条件查询、基础的数据校验以及简单的关联查询。

为什么适合 AI：

CRUD 是工程里最模式化的部分，AI 处理这类逻辑的效率远超人类。

注意边界：

权限控制不能交给 AI 默认生成
批量操作和事务边界需要人工确认
复杂的多表聚合查询建议人工编写或深度 review
软删除、审计字段等业务规则要在提示词中明确告知 AI

4. 测试用例

具体指什么：

单元测试骨架、边界值用例、异常分支用例、Mock 数据构造。

为什么适合 AI：

AI 擅长穷举，比人类更容易想到那些容易被忽略的"边缘场景"和"异常分支"。

注意边界：

测试断言（Assert）必须由人工确认是否符合真实的业务预期
警惕 AI 生成"看起来跑通了但实际没测到痛点"的无效测试
集成测试和端到端测试的关键路径仍需人工设计

5. 文档初稿

具体指什么：

接口文档、README、部署说明、代码注释、架构图的文字描述初稿。

为什么适合 AI：

从已有代码反推文档，AI 做得又快又全，能极大缓解程序员"讨厌写文档"的痛点。

注意边界：

文档必须与系统的真实行为一致，不能仅凭代码字面意思
业务背景、历史踩坑记录需要人工补充
文档必须有人负责持续更新，否则很快过期

6. 代码解释

具体指什么：

解释一段陌生的遗留代码、翻译报错信息、说明某个依赖库的作用、解析某种设计模式的实现。

为什么适合 AI：

AI 是一个极好的"翻译器"和"全天候导师"，能快速降低开发者的理解门槛。

注意边界：

AI 有时会"一本正经地胡说八道"，解释得看似合理实则错误
关键逻辑必须以实际运行结果为准
绝不能用 AI 的解释替代自己亲自阅读源码的过程

三、人做：必须由人把控的"脑力活"

如果说 AI 是执行者，那么人就是掌舵者。涉及上下文、代价权衡、长期影响和核心价值的部分，只能由人来完成。

1. 架构决策

具体指什么：

单体还是微服务？同步还是异步？选什么数据库和消息队列？模块如何划分？技术栈如何演进？

为什么必须人做：

架构决策不仅仅是技术问题，它深度绑定着团队能力、业务节奏、组织结构和长期维护成本。AI 没有这些现实上下文。

人要做的事：

列出候选方案，明确每个方案的代价与收益，做权衡并记录决策理由（ADR），最终为结果负责。

2. 关键路径

具体指什么：

核心业务链路、高并发 / 高可用节点、资金 / 订单 / 权限等敏感逻辑、系统性能瓶颈点。

为什么必须人做：

关键路径一旦出错，影响是灾难性的。AI 生成的代码在"正常路径"下通常没问题，但在异常、并发、极端边界场景下极易翻车。

人要做的事：

亲自设计或深度参与编码，主导压力测试和故障演练，制定清晰的降级和回滚方案。

3. 安全

具体指什么：

认证授权、会话管理、输入校验、防注入 / XSS、密钥管理、数据加密、越权防护。

为什么必须人做：

安全是"一票否决"的红线。AI 生成的安全代码往往"看似正确，实则存在漏洞"，攻击者同样在使用 AI 寻找这些漏洞。

人要做的事：

安全方案必须由人工设计，关键代码必须人工逐行 review，定期引入专业的安全扫描和渗透测试。

4. 性能

具体指什么：

接口响应时间、数据库索引设计与慢查询优化、缓存策略、并发处理能力、资源占用率。

为什么必须人做：

性能问题往往在真实流量冲击下才会暴露。AI 没有线上监控数据，无法做出符合当前系统体量的真实性能判断。

人要做的事：

定义性能指标（SLA），进行压测和调优，监控线上表现，为容量规划负责。

5. 业务逻辑

具体指什么：

业务规则、状态流转、异常处理策略、边界条件、合规要求。

为什么必须人做：

业务逻辑是软件的核心价值所在。AI 只能根据你描述的规则去生成代码，它无法判断你的规则本身是否合理、是否自相矛盾。

人要做的事：

把业务规则想清楚、讲明白，确认 AI 的实现完全符合业务预期，妥善处理规则冲突和例外情况。

6. Review（审查）

具体指什么：

代码 review、设计 review、测试 review、上线 review。

为什么必须人做：

Review 本质上是责任的体现。AI 无法为代码背锅，只有人能。

人要做的事：

检查逻辑正确性、安全性和性能，评估可维护性，并在心里问自己一个问题："我愿意为这段代码负责吗？"

四、数据与合规：AI 碰不得的红线

数据和合规是独立于技术之外的风险，一旦出问题，往往是法律层面的。

AI 能做：

生成合规检查清单初稿
整理隐私政策模板
提示常见风险点

人必须做：

判断数据来源合法性
用户隐私保护（个人信息保护法、GDPR）
数据跨境传输合规
数据脱敏、留存、删除策略
确认 AI 训练数据是否含敏感信息
法律审查与合规判断

边界： AI 可以提示风险，但不能替你承担法律责任。

五、测试的完整体系：不止单元测试

测试不是"跑通就行"，而是一套完整体系。

AI 能做：

生成单元测试用例、测试脚本
构造 Mock 数据
生成回归测试清单

人必须做：

设计测试策略（测什么、测到什么程度）
集成测试、端到端测试的关键路径设计
性能测试、安全测试方案
验收测试（UAT）标准
测试环境与数据管理
判断测试是否充分

边界： AI 能生成测试，但不能判断"测够了没有"。

六、运维与可观测性：上线后怎么活

上线不是终点，而是起点。

AI 能做：

生成监控配置、告警规则初稿
日志解析、异常归类
生成运维脚本

人必须做：

定义 SLO / SLA
设计日志、监控、告警体系
链路追踪与容量规划
故障演练、混沌工程
值班与应急预案
成本监控（云资源、API 调用）
为线上稳定性负责

边界： AI 能配监控，但不能在凌晨三点被叫起来修故障。

七、上线与发布：别让"能跑"变成"能用"

AI 能做：

生成发布脚本、检查清单
生成数据库迁移脚本初稿
生成回滚方案初稿

人必须做：

拍板发布策略：灰度、蓝绿、金丝雀
确认回滚方案可行
数据库迁移的风险评估
配置管理与发布审批
为发布结果负责

边界： AI 能写脚本，但不能替你按发布按钮。

八、团队与协作：从个人到组织

AI 协作不是个人行为，而是团队能力。

AI 能做：

生成代码规范初稿、CI 配置
生成 PR 模板、Review 清单
辅助新人理解代码

人必须做：

定代码规范与统一标准
设计分支策略、CI/CD 流程
建立 Code Review 机制
知识沉淀与交接
统一管理 AI 工具（谁能用、用什么、怎么审计）
带团队、建流程

边界： AI 能写规范，但不能替团队建立协作文化。

九、成本与资源：钱也是工程约束

AI 能做：

成本估算初稿
云资源用量分析
方案成本对比

人必须做：

AI API 调用成本控制
云资源预算
人力成本评估
技术债的长期成本判断
自建 vs 采购的权衡
ROI 决策

边界： AI 能算账，但不能替你做预算决策。

十、伦理与版权：AI 时代的法律边界

AI 能做：

提示常见风险
整理开源协议清单

人必须做：

AI 生成代码的版权归属判断
开源协议冲突审查
生成内容是否侵权的判断
是否披露使用了 AI
对用户的影响评估（如 AI 决策的公平性）
承担法律责任

边界： AI 能提示，但不能替你担责。

十一、AI 自身的风险：别把工具当真理

AI 不是万能的，它本身就有风险。

人必须做：

幻觉：AI 可能编造不存在的 API、库、配置
过时：训练数据截止，可能给出已废弃的写法
安全：AI 可能生成含漏洞的代码
一致性：同一问题多次生成结果不同
可解释性：AI 为什么这么写，往往说不清
供应商锁定：依赖某家 AI，迁移成本高

边界： 验证、审查、不盲信，是人必须守住的底线。

十二、度量与改进：怎么知道做得好不好

AI 能做：

数据收集、指标计算
生成报表初稿

人必须做：

定义度量指标
衡量 AI 带来的效率提升
衡量代码质量变化
统计 AI 生成代码的缺陷率
统计 Review 发现问题的比例
评估团队对 AI 的接受度
持续改进

边界： AI 能给数据，但不能替你定义"什么叫好"。

十三、守住边界：AI 生成的代码，必须有人 Review 并负责

引入 AI 后，最容易崩塌的就是团队的责任心。因此，必须确立以下铁律：

AI 是生成者，不是责任人。

代码出了生产事故，不能怪 AI。谁点击了 Merge，谁批准了上线，谁就承担全部责任。
Review 绝不是走过场。

不能因为"这是 AI 写的，应该没问题"就快速通过。你必须理解代码在做什么，确认边界、异常、安全和性能都已被妥善处理。
"看不懂就合并"是绝对禁忌。

如果 Reviewer 看不懂 AI 生成的某段复杂逻辑，那这段代码就不该进入主干。
责任链条必须清晰。

谁用 AI 生成的、谁 Review 的、谁上线的，都要有迹可循。出了问题要能追溯到具体的"人"，而不是甩锅给"AI 写的"。
AI 生成比例越高，Review 标准应越严。

代码量瞬间膨胀意味着风险同步放大。绝不能因为"AI 写得快"就降低工程质量的标准。

十四、坚守原则：AI 可以提速，但不能替代判断

最后，我们需要在认知层面达成团队共识：

AI 提速的是"执行"，而非"决策"。

写代码快，不代表技术选型对；生成得快，不代表系统设计好；改得快，不代表改得对。
判断力才是工程师最稀缺的资源。

判断什么该做、什么不该做；判断什么现在做、什么以后做；判断什么交给 AI、什么自己来------这是人类工程师不可替代的价值。
AI 放大的是人的能力，而非弥补人的短板。

优秀的工程师用 AI 如虎添翼；而缺乏基本功的人，只会用 AI 更快地写出一个难以维护的烂系统。
绝不能把"判断"外包给 AI。

AI 可以给建议、列方案，但它不能替你做决定，更不能替你承担后果。
最终的检验标准只有一个：你敢不敢为这段代码负责？

敢，就可以用 AI 生成；不敢，就自己写或者深度参与重写。责任，永远不能外包。