一、全局地图
用户在写代码这件事上的价值迁移 │ ├─ 层 1｜认知层：Vibe Coding 是什么，我的优势在哪，成本怎么控 │ ├─ 层 2｜底线层：Git 恢复点、数据隔离、备份、环境核对、文档先行 │ ├─ 层 3｜流程层：规约驱动 SDD、三件套 OpenSpec/Superpowers/gstack │ ├─ 层 4｜原理层：Claude Code 架构、工具、子 Agent、安全、记忆 │ ├─ 检索原理：为什么 grep 而不是 RAG │ └─ 上下文原理：Auto-Compact 压缩什么 │ ├─ 层 5｜系统层：Loop Engineering（循环怎么转）＋ Harness Engineering（整套外壳） │ └─ 层 6｜可靠性层：幻觉分层约束、上下文漂移、工具调用幻觉
AI 输出质量的上限由人的输入质量决定。人负责「定义问题—构建上下文—验证结果—做决策—控成本」，AI 负责「生成」。
三者不是替代关系，是包含关系：Prompt ⊂ Context ⊂ Harness。当任务还是单轮对话，Prompt 就够；需要外部知识，Context 关键；进入"长链路、可执行、低容错"的真实场景，Harness 几乎不可避免。
二、Vibe Coding 的准确定义与边界
2025 年 2 月 Karpathy 提出这个词时定义很明确：不审查、不理解、直接 Accept AI 生成的代码。
三、AI 越来越强，程序员的五项不可替代能力
这是最高频的灵魂问题："在 vibe coding 盛行、基模越来越强的今天，你的优势是什么？"❌ "AI 做不了 XX" → 防守型，越守越窄，等 AI 能做你就没了✅ "AI 做什么都需要你先做对什么" → 驱动型，越用越强优势一：问题定义能力
"加个退款功能"不是需求，是一句话。真正的需求定义要回答：部分退款怎么处理？退款和优惠券的互斥规则？多次退款的幂等性？退款超时怎么自动关闭？AI 不知道，产品经理也没说清楚。是你把一句话变成可执行的规格。AI 很强，但它需要精确的问题定义。我的优势是能把模糊需求拆成清晰的技术规格——边界条件、异常处理、业务规则，这些 AI 不会主动问你，但不说清楚代码一定写不对。
优势二：上下文构建能力
A 说"写一个退款接口" → AI 凭想象写，大概率不符合业务B 给了业务规则 + 表结构 + 上下游接口文档 → 代码基本能直接用差距不是 AI 的能力，是喂进去的上下文质量。三个要点：知道给什么、知道不给什么（10 万行无关代码既费 Token 又干扰模型）、知道怎么组织（先背景后需求）。同一个工具，高手和新人效果差 10 倍。不是工具不同，是输入不同。
优势三：结果验证能力
代码跑起来 ≠ 代码对了。AI 最危险的是"合理但错误"的代码：逻辑通顺、能跑通、语义和业务需求不一致。典型例子：退款接口返回成功但退到了错误账户；权限校验通过但用了错误角色；数据处理完成但精度丢了两位小数。这些 bug 测试发现不了，因为测试是按你的预期写的。验证要分层：业务语义验证 + 边界验证 + 回归验证。这种"合理但错误"的代码最容易通过 Code Review，因为看起来真的很合理。
优势四：技术决策能力
AI 能列方案 A/B 的 pros-cons，但拍板是你：选型决策：Redis vs Memcached、gRPC vs REST架构决策：微服务 vs 单体、同步 vs 异步、短期快 vs 长期稳成本决策：花 3 天重构还是 3 个月重构、用贵模型还是便宜模型AI 的建议是通用的，你的决策是具体的。例：AI 会说"高并发用缓存"，但不会告诉你"我们团队的缓存出过两次线上事故，这次要多加一层降级"。优势五：成本控制能力
一次 Claude Code 交互可能消耗 5 万～20 万 Token，一个项目跑下来 Token 费用可能比工程师工资还高。详见下一节。五大优势总结
你的优势不是比 AI 写得好，是让 AI 写得更好。
四、Token 成本控制五策略
| | |
|---|
| | |
| | |
| | |
| 模板 + Prompt Caching，不从零生成 | |
| | |
策略一：模型路由——什么活用什么模型
大模型输出价格是小模型近 20 倍。若 70% 任务能用小模型，整体成本降 60%+。工具内部已在做（Claude Code 的双模型策略），但面试官想听的不是"工具自动做了"，而是你理解为什么这么做。策略二：上下文管理——别把整个代码库塞进去
定期清理上下文：长对话积累历史 Token，该开新会话就开只给相关代码 vs 给整个项目，Token 消耗差 3～5 倍。更关键的一点：无关代码越多，生成质量反而越差——无关信息干扰模型注意力。所以上下文管理不只是省钱，也在提升质量。策略三：Prompt 优化——一次说清楚
模糊 Prompt → 不符合预期 → 再改 → 还是不对 → 再改……一次说清楚可省掉 3～4 轮。四要素：说清目标（不是"写个接口"，是"REST 接口，接收退款请求，参数含订单号和金额，需幂等校验"）、说清约束（性能/安全/规范）、说清上下文（表结构、上下游接口）、给示例（一个具体输入输出示例胜过 100 字描述）。成本对比：一次精确 Prompt ≈ 500 Token，四轮模糊 Prompt ≈ 12000 Token，差 24 倍（还没算时间）。策略四：缓存和复用
Prompt 缓存：Anthropic API 原生支持 Prompt Caching，相同前缀输入可打到 90% 缓存命中率代码模板：常见 CRUD、表单验证维护模板，AI 只填差异策略五：任务评估——哪些任务让 AI 做更贵
适合 AI：重复性高模式固定的代码（CRUD、样板）、你知道要什么但手写太慢、需要快速探索多方案、不熟悉语言/框架的入门代码。不适合 AI：改一行配置就解决的小修改、你非常熟悉的代码区域（手写比解释更快）、需要深度业务理解的决策型代码、已有精确模板复制粘贴更快的情况。反例（很典型）：线上 NPE，你翻日志定位到 OrderService.java:127 user.getAddress() 没做空判断，加一行 if 10 秒搞定。但如果你不看具体位置、直接把报错粘给 AI：AI 读报错 → 读文件 → 分析上下文 → 生成修复 → 自查，至少 10k token（文件大就是几十 k），你还得审查它有没有改错地方。10 秒的手工活变成 3 分钟的 AI 交互，还更贵。
五、Vibe Coding 工程避坑
核心结论：Vibe Coding 真正难的地方，不是"让 AI 干活"，而是知道什么时候让 AI 干、怎么让 AI 干、干错了怎么退回来。1. 不会 Git，别让 AI 大规模改代码
2. 不要让 AI 一口气完成整个项目
"帮我做一个完整系统"（登录 + 文章 + 评论 + 后台 + 上传 + 搜索 + 部署）→ AI 给你一个完整项目，但细节全是问题：权限边界不清、错误处理随意、表设计临时拼、前端状态到处传、后台权限形同虚设、测试基本没有、部署配置和本地混在一起。这不是 AI 不会写，是你让它在超大上下文里同时做太多决策。正确做法是小步闭环：登录注册 → 跑通提交 → 文章 CRUD → 跑通提交 → 评论 → 上传搜索 → 最后部署。每一步告诉 AI：只改哪些文件、哪些模块不要动、怎么验证完成、失败怎么回退。AI 可以帮你写模块，但不能替你做架构拆分。架构拆分是人的责任。
3. 数据库操作必须默认高危
建表、删表、改字段、导入导出、数据清洗、初始化脚本都算高危。动手前必须问：有没有备份？能不能回滚？操作的是测试库还是生产库？没有备份不做，不能回滚要谨慎，分不清环境绝对不能执行。尤其不要随口说"帮我重置数据库"——重置哪个库？保留哪些表？有没有备份？是不是生产环境？没写清楚 AI 只能按字面执行。数据库操作不要让 AI 直接干，先让它生成脚本和风险说明，再人工确认。
4. 给 AI 任务时，要写"不能做什么"
AI 的默认倾向是"完成任务"。你只说"修好"，它可能为了修好而扩大改动范围。而工程协作最怕的就是改动范围失控。5. 先沉淀文档，再开发功能
不写文档直接改代码，一个月后项目变黑盒——你自己都不知道功能怎么实现的，换个 AI 工具更是抓瞎。正确流程：先让 AI 生成技术文档 → 人扫一遍确认 → 再让 AI 写代码 → 完成后让 AI 更新文档。文档内容：流程（下单 → 调起支付 → 回调确认 → 更新订单状态）、表设计、接口设计、异常处理（超时/重复支付/金额校验）、安全措施（签名/幂等/加密）。根目录建 docs/，按模块分：docs/auth.md、docs/payment.md在 CLAUDE.md 写文档映射规则（开发登录功能时先读 docs/auth.md…）开发前让 AI 补文档，完成后让 AI 同步实际实现文档不是给开发人员看的，是给下一个接手这个项目的 AI 看的。今天用 Claude Code，明天可能换 Cursor，后天换 Codex——有文档，切换成本直线下降。
六、Spec-Driven Development 规约驱动开发
为什么 AI 越快，越要先写清楚
真实场景：你说"帮我加个会员续费功能"，几分钟后接口、页面、字段、回调全写出来，测试也是绿的。但一问细节：未过期会员续费从原到期日顺延还是从付款日重算？回调重复到达会不会重复加时长？"不能改旧接口"在压缩后忘了？一个任务改了十几个文件，Review 时找不到从哪一步跑偏？测试验证的是 AI 自己写的逻辑而不是你的业务规则？不是 AI 不会写，恰恰是因为它写得太快，模糊需求、错误假设和遗漏边界也被一起快速放大了。
缺的不是更强的模型，而是一份人和 AI 共同确认的规约：做什么、不做什么、边界在哪、什么结果算完成。定义
SDD 是一种以规约为核心工件的开发方式。团队先把目标、用户行为、边界条件和验收标准写成可审查的规约，再由规约推导技术方案、实施任务、代码和测试，并在需求变化或实现反馈出现时持续同步规约。
规约不是一篇大作文—— 要回答：为什么做/解决谁的问题、用户能做什么/系统必须表现成什么样、哪些边界必须处理/哪些明确不做、什么算完成/拿什么证据验收、非功能约束是什么。格式不是重点，能不能减少歧义、驱动后续动作才是。规约要能一路追到代码和测试—— 用户意图 → 行为规约 → 技术方案 → 可执行任务 → 代码与测试 → 验收证据。每个任务能回答"对应哪条需求"，每条验收标准能回答"由哪个测试证明"。规约不是写完就锁死—— 实现发现要回流到规约再确认，是"活的规约"，不是一次性大前期设计。为什么在 AI 时代重新火
代码生成成本突然下降：瓶颈从"怎么写代码"转向"到底该写什么"。AI 很能执行，但不会读心：面对缺失信息它不会停下等你，而是补出一个"最像正确答案"的方案——合理不等于符合你的业务。标志性动作：GitHub 2025 年 9 月开源Spec Kit（Specify → Plan → Tasks → Implement）；Kiro2025 年 7 月把 requirements / design / tasks 做成 Agent 可持续读取执行的工件。本质变化：自然语言规约第一次可以被 Agent 直接消费，规约从"给人看的文档"变成"人和 Agent 共同执行的接口"。没有规约的五类问题
模糊需求 → 假设爆炸：一个假设错了是小 Bug，十几个假设互相影响就是整条业务链路返工。聊天记录不是可靠的项目记忆：上午说"不要改旧接口"，下午压缩后忘了；换窗口没了；同事接手只能从代码反推意图。任务太大 → 一路跑偏："帮我把会员系统做完"不是任务，是愿望。上千行 diff 的 Review 是灾难。"代码写完"和"需求完成"被混为一谈：测试可能只覆盖了 AI 自己选的 happy path。错误被高速复制：人工写错一天产出几百行，AI 理解错几分钟扩散到接口、数据库、测试、文档。六步流程
| | |
|---|
| | 写行为和边界，不是先规定 Controller 有几个类 |
| | |
| 改哪些模块/不能动哪些、数据结构与接口契约、状态流转、异常恢复、测试分层、选型理由 | |
| 小到能单独 Review、单独测试、能追到某条规约 | |
| 看 diff、看测试通过什么、有没有改规约外代码、有没有遗留假设、能否追溯到验收标准 | 规约不替代 Review，规约是让 Review 有尺子 |
| | 否则出现三套事实：规约一套、代码一套、口头理解一套 |
最小规约模板：
功能名称：背景与目标：为什么做，解决谁的问题，成功结果是什么。核心场景：用户在什么条件下做什么，系统应该返回什么结果。边界与异常：失败、重复、超时、并发、权限不足时怎么办。非目标：这次明确不做什么。技术约束：必须遵守的架构、接口、安全、性能和兼容要求。验收标准：每条标准对应什么测试或检查证据。实施任务：拆成可独立实现、Review 和验证的小任务。
SDD vs 其他概念（易混点）
| |
|---|
| PRD 只讲产品需求；SDD 覆盖从需求规约到设计、任务、实现、验证的更长链路。PRD 可成为规约的一部分，但一份 PRD ≠ 完整 SDD |
| TDD 用测试先定义代码行为再写最小实现；SDD 从用户意图和系统边界开始，验收标准再下沉成测试。两者最适合组合 |
| BDD 的 Given-When-Then 场景可直接成为 SDD 的行为规约与验收标准，但 SDD 还覆盖技术设计、任务拆分、变更同步 |
| 表面都强调"先想清楚"，但现代 SDD 强调小步迭代和双向反馈，反对的是无规约乱冲，不是要求一次写死未来变化 |
| 超长 Prompt 仍是一次对话输入；规约是版本管理、可 Review、可追溯、跨会话复用的项目工件 |
规约维护的三个层次
六个落地坑
AI 写完规约人直接点确认—— 和让 AI 写完代码直接 Accept 没区别，规约的价值来自审查，不来自文件数量。把规约写成实现说明书—— 需求阶段就写死类名、方法名、字段，把探索空间提前堵死。规约越来越长却找不到关键约束—— 关键目标、边界、非目标、验收标准必须醒目，历史讨论另存决策记录。代码变了规约没变—— 一旦团队发现规约常过期就不会再信它，SDD 退化成"文档表演"。只验证"有没有做"，不验证"做得对不对"—— 任务打勾是进度，不是证据。任何小改动都套完整流程—— 改一个错别字写三份文档不叫工程化，叫形式主义。按风险分层。
七、AI 增强开发三件套：OpenSpec / Superpowers / gstack
与 Vibe Coding 的本质区别
Vibe Coding 是把 AI 当成一次性代码生成器；AI 增强开发是把 AI 放进工程闭环。前者关注"能不能写出来"，后者关注"需求是否清楚、实现是否符合规格、测试是否覆盖边界、上线是否可控"。
Vibe Coding 的致命问题：需求、设计、验证、交付全靠聊天过程临时维持。上下文一长、换窗口、中途改方向，Agent 很容易忘掉最初的约束。为什么光有 Claude Code / Codex 不够
强模型解决的是能力问题，不是流程问题。再强的 Agent 也会：需求没澄清就开写、只实现 happy path、测试写得像在证明自己没错、Review 只看表面、真实流程没走一遍、上线后不复盘。根因：Agent 的默认倾向是"尽快完成用户请求"，而成熟工程师会先问：解决谁的问题？哪些场景必须支持？哪些边界不能碰？失败后怎么恢复？影响哪些模块？怎么证明它真的对？一句话：模型负责生成，三件套负责约束生成。
三层分工
| | | |
|---|
| | spec、proposal、design、tasks、spec delta | |
| | | |
| | plan review、browser QA、ship checklist、retro | |
OpenSpec（轻量级 spec-driven framework，支持 Claude Code / Cursor / Codex / Copilot）：
每次变更产生spec delta，方便审查需求变化典型结构：openspec/specs//spec.md + openspec/changes//{proposal,design,tasks}.md核心价值不是"帮我写计划"，而是把需求意图变成可版本管理、可审查、可复用的规格。它解决 AI 开发最容易失控的上游问题：需求没定义清楚，Agent 就开始写代码。
Superpowers（给 coding agents 的完整软件开发方法论，基于可组合 skills）：
先澄清你到底要什么 → 整理成 spec → 分块确认设计 → 生成 implementation plan强调red/green TDD、YAGNI、DRY用subagent-driven development执行，每个任务完成检查和 Review关键洞察：AI 当然会写测试，但默认是"代码写完后补测试"，这类测试很容易变成证明题——证明自己刚写的代码没错。red/green TDD 逼 Agent 先明确行为预期，而不是直接堆实现。
gstack（定位是 AI coding 的 delivery loop，不是一堆 prompt）：
| | |
|---|
| | |
| /plan-eng-review /plan-design-review | |
| | |
| | |
| | |
| | |
| | |
Browser QA 是关键：很多 AI 代码"测试通过"但页面一打开就露馅——按钮被挡住、表单状态没清、移动端布局炸了、登录态下流程不对、错误提示压根没出现。单靠单测发现不了。AI 写的是代码，但用户用的是产品。
组合关系（按链路讲，别按工具罗列）
OpenSpec（做什么）→ Superpowers（怎么做）→ gstack（怎么交付） 规格层 执行纪律层 交付闭环层
什么时候用，什么时候别用
适合：支付/订单/会员/权限等核心业务；一次改动跨前后端、数据库、任务队列；需求边界多失败场景多；新人或 Agent 不熟项目；需要 Review 需求变化而不只是代码；上线出错代价高。判断标准（一句话）：错误只影响局部样式 → 轻流程；错误会影响钱、权限、数据一致性、用户主流程 → 上规格和交付闭环。收尾金句：成熟的 AI 编程，不是让 Agent 写得更多，而是让 Agent 在正确约束下写得更可靠。不是和 AI 比谁敲代码快，而是你能不能把 AI 管成一个靠谱的工程队友。
总结
认知类问题
差：AI 做不了复杂业务逻辑和安全代码。好：AI 确实越来越强，很多之前说 AI 做不了的场景现在都做得不错。但 AI 的输出质量直接取决于人的输入质量——定义问题、构建上下文、验证结果、做决策、控成本，这五件事 AI 替代不了我。我的优势不是比 AI 写得好，是让 AI 写得更好。
判断标准不是"AI 做得了还是做不了"，而是**"这段代码出 bug 的代价有多大"和"AI 写和手写哪个综合成本更低"**。代价大 → 自己写或严格审查；代价小 → 让 AI 加速。
重点查三样：业务语义（行为是否符合业务意图）、安全风险（输入校验、权限控制、敏感数据）、工程性（性能、可维护性、规范一致性）。特别警惕"合理但错误"的代码——逻辑通顺、能跑通、语义不对，最容易漏过 Review。
三步：先止血（回滚/降级，不管是不是 AI 写的处理方式一样）→ 再定因（看监控确认影响范围、看日志追调用链路；如果是 AI 代码，还要想清楚审查时为什么没拦住——安全没审到？边界没覆盖？业务语义理解偏差？）→ 最后补流程（补测试用例、加强审查重点、调整哪些场景允许 AI 生成）。一个 bug 不可怕，同类 bug 再出一次才可怕。
Q：AI 写的代码出问题，让 AI 修也修不好，怎么兜底？这个问题确实会发生——AI 对线上环境没有感知，或问题根因涉及多模块交互，上下文里装不下全局。兜底关键是你不能等 AI 来救你：① 先止血（回滚到上个稳定版本，用户等不了）② 自己排查（看日志、监控、链路追踪定位根因——你审查 AI 代码时积累的理解这时就派上用场了；如果当时是"看着没问题就过了"，排查起来和看别人代码没区别）③ 自己改代码走正常测试发布 ④ 复盘为什么 AI 修不好（上下文不够？超出能力范围？），结论决定下次类似问题还要不要交给 AI。说到底，AI 修不了的时候，你得能修，这是底线。
四件事：代码归属（谁 Accept 谁负责）、审查流程（AI 代码走和人工代码一样的 Review）、监控指标（追踪 AI 代码的 Bug 率和漏洞率）、持续优化（根据数据调整 AI 使用策略）。
AI 工具都有代码上传行为（发送到服务端推理，厂商说不用于训练，但合规部门不一定买账）。实际操作：① 敏感代码不上传（核心算法、密钥管理、交易策略不在 AI 工具里打开）② 用企业版而非个人版（有数据隔离协议）③ 配置 .gitignore / .claudeignore 排除敏感目录 ④ 团队统一规范（哪些项目能用 AI 写进开发规范，新人入职就知道边界）。
工程类问题
五策略：模型路由（70% 任务用小模型，降 60%+）、上下文管理（只给相关代码，降 3～5 倍）、Prompt 优化（一次说清楚，往返降 3～4 倍）、缓存复用（模板 + Prompt Caching，降 50%+）、任务评估（不该用的别用）。核心是在成本和质量之间找平衡，不是越便宜越好，也不是越贵越好。
Q：AI 增强开发和普通 AI 辅助编程有什么区别？普通 AI 辅助编程更像局部提效（补代码、解释报错、生成测试）。AI 增强开发强调把 AI 纳入完整工程流程，从需求规格、设计、实现、测试、Review 到发布复盘都由流程约束。区别不在于是否使用 AI，而在于 AI 是否被工程化治理。 补充一句：如果没有规格和验证，AI 越强，越可能把错误快速放大。
Q：为什么 OpenSpec 比一个详细 Prompt 更可靠？详细 Prompt 只能服务当前聊天窗口；OpenSpec 把需求规格放进仓库，能被版本管理、Review，也能跨会话复用。对 Agent 来说不是临时上下文而是长期上下文；对团队来说不只是给 AI 看，也是给人审查需求变化用的。
Q：Superpowers 解决的是模型能力问题吗？不是，解决的是 Agent 工作习惯问题。强模型也会急着开写、跳过澄清、测试写得不严谨。Superpowers 用 skills 和方法论让 Agent 先澄清、再设计、再计划、按 TDD 和任务拆分执行——核心是把工程纪律变成默认行为。
Q：gstack 为什么强调 Review 和 QA？因为 AI 生成代码最危险的地方是"看起来完成了"。代码能编译、测试能过，不代表用户流程真没问题。gstack 把 Review、Browser QA、Ship、Retro 纳入交付闭环，防止 AI 写完直接跳过团队原本会做的工程检查。
不会一上来全量铺开，而是按风险分层。 低风险小改动直接用 Claude Code/Codex + 简单 Review；涉及核心业务逻辑、跨模块改动、支付权限数据一致性，先用 OpenSpec 写清规格，再用 Superpowers 按任务和 TDD 执行，最后用 gstack 做 Review、浏览器 QA 和 Ship 检查。→ 这个回答说明你不是工具党，知道什么时候加流程、什么时候不要过度工程化。
定义（见第六节）。解决四类问题：① 减少模糊需求导致的假设错误 ② 把关键上下文从聊天迁移到可版本管理的长期工件 ③ 用小任务和检查点限制 Agent 跑偏的影响半径 ④ 用验收标准区分"代码生成完成"和"需求真正完成"。
不一定。现代 SDD 强调可执行、可演进的规约，不是一次性写完所有文档；规约、设计、任务、实现之间可双向反馈，小步确认、小步生成、小步验证。真正要避免的是无边界直接开写，而不是禁止迭代。
人负责定义问题、做业务和技术取舍、审查规约、处理冲突、对验收负责；Agent 负责研究、拆解、实现、执行验证。AI 可以生成规约草稿，但不能替团队决定什么才是正确需求。
总结
认知
你的优势不是比 AI 写得好，是让 AI 写得更好。不是"AI 做不了"，是"AI 需要你"。前者是防守，越守越窄；后者是驱动，越用越强。同一个工具，高手和新人效果差 10 倍——不是工具不同，是输入不同。工程
没有 Git，Vibe Coding 不是开发，是赌命。成熟工程师和新手的区别，不是不犯错，是出错后能回来。文档不是给开发人员看的，是给下一个接手这个项目的 AI 看的。流程
规约不替代 Review，规约是让 Review 有尺子。不是和 AI 比谁敲代码快，而是你能不能把 AI 管成一个靠谱的工程队友。原理
Agent 架构没有魔法，就是 while 循环。架构不复杂，工程细节才是壁垒。一个没有权限控制的 AI Agent，就像一个有 root 权限的实习生。把确定性工具交给模型，把检索决策权还给模型，让模型在多轮工具反馈中逐步逼近答案。代码理解不是把仓库倒进模型，而是把模型需要的证据逐步拿出来。Agent 爆上下文，不是因为用户说得多，而是因为工具调用轨迹太重。上下文压缩不是尽量不丢信息，而是优先不丢会影响下一步行动的信息。上下文漂移的本质，是原始目标在注意力分配中逐渐失焦。系统
换模型提升的是天花板，搭 Harness 提升的是落地能力。Agent 反复失败时，别问模型能不能更努力，要问环境还缺什么。技术债几乎永远应该每天小额还一点，而不是攒着等某一天集中还。三条自我检查清单
用 AI 写代码前
让 AI 改代码时
涉及数据库/部署/危险命令，是"只生成脚本"还是"直接执行"？AI 改完之后
