第 1 篇的 22 句解决“怎么把 AI 用起来且不翻车”。这一篇只补齐 5 个缺口：安全、评审、上下文、工具链、适用边界。仍然坚持：每句=原则 + 可操作约束/验收方式，不凑数。
一、安全与合规（把风险控制在键盘前）
- 默认“最小泄露原则”：任何敏感信息先脱敏再提问。
约束：密钥/Token/证书/客户数据/生产日志不得原样粘贴；验收：你能解释“我发出去的每个字段是否必要”。 - 把“数据分类”写成 3 档规则并执行：可公开/内部/敏感。
约束：敏感档一律不进 AI；验收：你能在 10 秒内判断某段内容属于哪一档。 - 对必须引用的业务数据，用“结构替换”而不是“原文复制”。
约束：用字段结构+假数据替代真实值；验收：AI 仍能给出有效方案且不包含真实信息。 - 任何会触发“越权/绕过鉴权/注入风险”的建议都先当成红旗。
约束：AI 若建议关闭鉴权/放宽校验/拼接 SQL，必须改为安全实现；验收：方案能通过安全审视（最少：鉴权、输入校验、输出转义）。
二、评审与反幻觉（把“看起来对”变成“确实对”）
- 让 AI 在输出前先列“我将修改的点 + 为什么 + 不改什么”。
约束：必须写“不改清单”；验收：你能快速判断是否会误伤系统边界。 - 让 AI 做“失败模式检查”：列出 5 种失败路径并逐项给处理策略。
约束：至少覆盖：空值/超时/重试/并发/权限；验收：每条都有具体处理（返回码、降级、日志）。 - 对关键逻辑强制“样例推演”：给 2–3 组输入，让 AI 写出逐步输出过程。
约束：不接受只给结论；验收：推演可手算/可对照日志验证。 - 每次采纳 AI 改动前，用“最小验证集”挡住幻觉：构建 + 测试 + 关键路径手测。
约束：验证集写成 3–5 条固定清单；验收：每条都有可复现证据（命令输出/截图/日志）。 - 让 AI 给“风险分级 + 回滚方案”，并把回滚做到一行命令/一个开关可执行。
约束：风险≥中则必须可回滚；验收：你能在 1 分钟内恢复到改动前状态。
三、上下文管理（让 Cursor 复用你的约束与代码库事实）
- 只提供“完成任务所需的最小上下文”，避免把 AI 淹没在噪音里。
约束：优先给接口签名、关键函数、错误栈、复现步骤；验收：AI 输出更聚焦，改动范围更小。 - 把“项目约定”沉淀成一段可复制的上下文引导，每次新会话先贴。
约束：包含：语言/框架/目录分层/错误处理/日志字段/代码风格；验收：不同对话生成的代码一致性明显提升。 - 当任务切换或需求变更时，新开对话并重写约束，禁止在旧线程里叠加冲突指令。
约束：旧结论只当参考；验收：AI 不会继续沿用过期假设。 - 对不确定信息要求 AI 显式标注“假设”，你只需要确认假设而不是重讲一遍需求。
约束：输出必须区分“已知事实/推断/假设”；验收：你能快速补齐关键缺口。 - 让 AI 先“问清楚再动手”：缺信息时必须先提 3–5 个澄清问题。
约束：没有澄清就不允许它写大段实现；验收：返工率下降。
四、工具链协同（AI 负责生产，人类用工具负责把关）
- 把工具链当作“事实裁判”：格式化、lint、类型检查、测试优先于任何解释。
约束：冲突时以工具输出为准；验收：最终改动能通过项目既有检查。 - 让 AI 按项目既有规范生成代码：同样的 formatter、同样的 lint 规则、同样的错误类型。
约束：禁止引入新风格/新库来“解决小问题”；验收：diff 看起来像同一团队写的。 - 将“验证命令”写进任务里，让 AI 输出后附带可复制的运行方式。
约束：必须给出 1–3 条命令（如 build/test/dev）；验收：你能立刻复现其声称的结果。 - 重构必须配套“回归信号”：至少新增或保留一条自动化检查作为护栏。
约束：没有护栏的重构先缩小范围；验收：后续改动不易把老问题带回来。 - 提交粒度以“可回滚、可定位”为标准：一次只解决一个问题域。
约束：不要把格式化、重构、功能混在一坨；验收：出问题时你能快速定位责任改动。
五、适用边界与任务选择（选对任务，AI 才会像开挂）
- AI 最擅长“明确输入输出”的任务：脚手架、迁移、批量重命名、测试补齐、文档生成。
约束：优先把这类任务交给 AI；验收：你能明显感觉“机械劳动减少”。 - AI 不擅长“需求不确定/强业务判断/高风险权限”的任务，先把需求写成验收标准再用 AI。
约束：验收标准不清就先澄清，不开写；验收：需求变更导致的返工下降。 - 遇到复杂系统改动，先让 AI 做“影响面分析”，再做实现。
约束：先列受影响模块、接口、数据结构；验收：你能提前发现破坏性改动。 - 对高风险模块（鉴权、支付、权限、数据删除）只让 AI 做“建议与测试”，实现由你主导。
约束：AI 产出必须被你逐行 review；验收：关键路径变更有双重验证（测试+手测/审计）。 - 任何“跨文件大改”先拆成小步增量，每步都能独立回归。
约束：一步一验收；验收：每步都有可运行的状态，不出现“改到一半不能跑”。
六、增量开发与协作姿势（让团队愿意用、敢于用）
- 让 AI 先写测试/用例再写实现，是把不确定性变成确定性的最快方式。
约束：至少 3 类用例（正常/边界/异常）；验收：先红后绿。 - 让 AI 输出“可观察性计划”：该打哪些日志、关键指标是什么、如何关联 requestId/traceId。
约束：日志不包含敏感信息；验收：线上问题能通过日志快速定位。 - 每次输出都要求“变更摘要 + 风险点 + 验证清单”，把它当作交付物的一部分。
约束：清单 ≤5 条且可执行；验收：任何同事照清单也能验证结果。 - 当你不确定 AI 方案是否正确，先让它给 2–3 个备选并说明 trade-off，再由你决策。
约束：必须说明性能/复杂度/兼容性影响；验收：你能基于取舍做决定而不是赌运气。 - 把 AI 产出的“隐性知识”变成显性文档：接口说明、边界条件、已知限制。
约束：文档 ≤10 行，贴近代码；验收：下次你/同事不用再问一遍相同问题。 - 把 AI 当“强力助理”，你当“责任 owner”：任何上线行为必须可回滚、可验证、可解释。
约束：不验证不合并，不可回滚不发布；验收：引入 AI 后交付更快且事故不增。
