AI 辅助编程不黑盒：责任主线工作流实战
副标题 / 摘要 你不需要“每个 commit 都手打重写”，但必须对核心 commit 具备独立实现能力。本文给出一套可落地的 AI 协作流程：让 AI 负责胶水和草稿，你负责领域规则、状态变化与边界裁决。 目标读者 正在大量使用 AI 写代码，但担心自己变成“黑盒工程师”的开发者 想同时提升交付效率和技术判断力的工程师 在做 DDD、业务系统或中后台项目的开发者 背景 / 动机 AI 代码生成越来越强，这不是坏事。真正的风险在于：当你只会“接收实现”，却不能解释“为何这样实现”，系统一复杂就失去控制权。 问题不是“要不要用 AI”，而是“哪些决策必须留在人手里”。 核心概念 责任主线（main）：只保留你愿意为其设计与后果负责的 commit。 AI 草稿（ai/draft-*）：一次性候选实现分支，用于对照、压力测试与发现盲区。 git worktree：在不二次 clone 的前提下，为不同分支创建多个物理目录（一个仓库，多处并行）。 核心 commit：包含领域规则、不变量、状态机、关键边界与失败路径的提交。 胶水 commit：CRUD、DTO、映射、样板接口、注释等可标准化提交。 硬核评价标准：去掉 AI 和网络，你仍能写出该 commit 的核心伪代码，并解释每一步为什么这么做。 实践指南 / 步骤 先分层，再决定谁写 把需求拆成 Domain / Application / Infrastructure。 Domain 核心规则优先自己实现；Infrastructure 优先交给 AI。 先写判断标准，再看 AI 方案 先写不变量、边界条件、错误路径、伪代码或测试，再生成 AI 草稿。 先有你的“尺子”，再拿 AI 代码来量。 为每轮任务创建短生命周期草稿分支 从当前 main 派生 ai/draft-<topic>，让 AI 快速给出候选实现。 草稿分支只做提议，不做长期维护。 ...