收益：
- 能够将编辑器完成、聊天助手、CLI 代理和 CI 自动化类别映射到任务
- 能够根据风险调整自主级别并对 CLI 代理应用“计划优先”原则
- 能够将人工智能的使用转变为基于经过验证的工具、验证门、透明度和问责制的团队系统
到目前为止，我们已经学会在各个任务（编码、审查、测试、调试）中使用人工智能。在最后一个单元中，我们将各个部分放在一起：了解不同的人工智能编码工具，将正确的工具与正确的工作相匹配，并将它们安全地嵌入到您的日常开发流程中——从编辑器到版本控制，从 CI/CD 管道到团队治理。目标是将杂乱的“时不时询问人工智能”的习惯转变为一致且可审计的工作系统。
我们用中性类别涵盖车辆类型（具体产品名称变化很快；重要的是类别的作用）。每个类别都有一个“最佳点”和风险状况；掌握是知道应该给予哪项任务多少自主权。
AI编码工具的类别
1. 编辑器内完成。当您在 IDE（您编写代码的开发环境）中键入时建议行/块的插件。最佳点：流内速度、样板代码。风险：语境狭窄，不加思考就接受建议。
2.聊天/侧面板助手。嵌入在 IDE 中的聊天界面可以查看部分代码库。最佳点：描述、重构、测试、错误分析。风险：仅限于您给出的上下文，需要验证。
3. CLI代理（代理工具）。从命令行运行的工具可以读取和修改多个文件、运行命令以及自行执行多步骤任务。最佳点：多文件更改、重复任务、“添加此属性”类型的作业。风险：高自主性=高影响力；如果不加以控制，它会产生广泛且难以验证的变化。
4. 生产线/自动化集成。 CI（持续集成）机器人会在 PR 上留下自动审核评论、建议测试或生成变更日志。最佳点：第一过滤器不疲劳、一致性。风险：噪音、虚假信心。
提示：随着自主权的增加，控制权也应该增加。由于编辑完成量小且瞬时，因此监督程度较轻； CLI 代理的多文件修改应该像人工 PR 一样进行检查，甚至更仔细。
一步一步：将人工智能嵌入到工作流程中
- 将任务映射到工具。少量流内添加 → 完成；理解/重构/测试→聊天；多文件、重复性工作 → CLI 代理；连续第一过滤器 → CI 集成。
- 选择自治级别。代理人有多少自由度？只读建议还是文件修改+命令执行？调整风险。
- 培育环境。将项目规则（风格、架构、“不该做的事情”）永久引入工具中；使用项目说明文件，而不是一遍又一遍地解释它。
- 维护验证门。人工智能的改变就像人类的改变：它要经过编译、测试、审查和（如果关键的话）专家批准。 AI开放PR不会绕过审批。
- 测量并调整。观察哪些地方真正加速了，哪些地方修正负担增加了；删除无效的用途。
三个迷你箱
案例 1 — CLI 代理处理多文件重命名。一个团队会对分布在 60 个文件中的一个概念进行重命名。他们将任务交给 CLI 代理，首先要求制定计划，批准该计划，然后进行更改并运行整个测试套件。特工 3 错过了档案中的一个边缘案例；测试发现了它，修复了它。这项工作原本需要大约 3 个小时的手工时间，但在监督下仅用了 50 分钟就完成了。
案例 2——不受约束的自主权适得其反。另一位开发人员告诉代理“改进这个模块”并发布了它；该代理修改了 18 个文件并添加了两个依赖项。这一变化范围如此之广，以至于无法对其进行审查，不得不撤回。教训：给代理缩小范围、明确的接受标准以及先计划后做的纪律。
案例 3 — CI 审核机器人成为第一个过滤器。一个团队构建了一个机器人，可以在 PR 上留下自动 AI 审核评论。一旦机器人发现空检查遗漏和风格问题，人类审阅者就可以将时间投入到业务逻辑上。然而，该团队明确表示，机器人并没有提供“批准”：仍然需要至少一个人类的批准。为了减少噪音，他们将船调整为仅留下高/中强度噪音。
四个可复制模板
CLI 代理的“先计划”原则：
任务：{{明确、狭窄的任务}}接受标准：{{可测量的结果}}约束：仅适用于{{以下目录/文件}}；添加新的依赖项。首先提出一个没有更改的计划：哪些文件，将更改哪些内容，要运行哪些测试。等我批准这个计划。然后逐步应用它，在每一步运行测试。
项目说明文件（工具的持久上下文）：
本项目中人工智能工具的持久规则：- 语言/版本：{{...}}。风格：{{...}}。- 架构约束：{{例如层之间的方向}}。- 永远不要：嵌入秘密、使用生产数据、{{禁止的库}}。- 每个更改都必须是可测试的；无需询问即可更改公共 API 签名。 - 如有疑问，请停下来询问。
任务工具映射决策：
我定义了以下任务：{{task}}。我应该使用哪类工具来完成此操作：(a) 编辑器完成、(b) 聊天助手、(c) CLI 代理、(d) CI 自动化？写下你的理由、风险和建议的自治级别（仅建议/更改文件/运行命令）。
CI 审查机器人行为准则：
仅留下“高”和“中”严重性结果作为 PR 审核中的评论。每个发现：类别、严重性、建议纠正。将风格偏好级别的注释收集到单独的单个摘要评论中。您不同意；需要人类的批准。
弱提示/强提示
弱：（对 CLI 代理）“让支付模块变得更好。”
Strong：（对 CLI 代理）“仅在 src/ payments/ 下运行。任务：将 returned() 函数中的递归验证逻辑提取到单个帮助程序中；行为和签名不会改变。首先提出计划并等待我的批准；然后执行并运行测试/付款/包。添加新的依赖项。”
强版本缩小了范围，设定了验收标准和约束，并实行“计划第一”的纪律。模糊的“做得更好”要求是巨大且不可控变化的根源。
车辆类别
他最擅长什么
自主权
检验重量
编辑完成
少量插播添加
低
光（即时读取）
聊天助手
理解、测试、重构
中等
中（输出验证）
CLI代理
多文件、递归
高
重（计划+全面审查）
CI自动化
连续第一过滤器
中等
中（规则+人工批准）
团队治理：从个人技能到共享系统
在个人基础上充分利用人工智能只是一个开始；真正的成熟是团队层面一致的系统。该系统基于几个支柱：批准的工具列表（哪些工具可以与哪些数据一起使用 - 来自单元 10）、验证门（AI 更改经过相同的构建/测试/审查门 - 来自单元 11）、透明度（说明更改是由 AI 驱动的，在必要时提供可追溯性）以及责任的明确性（签字和负责的人是明确的）。该框架在保持速度的同时限制了风险，并确保新的团队成员按照相同的纪律工作。
注意：工具（尤其是可以修改文件、运行命令的 CLI 代理）的自主权越高，对其访问生产环境、机密数据和难以恢复的操作的限制就越严格。将破坏性命令（永久删除、部署）与人工批准联系起来。
常见错误
- 任务——意味着不兼容。尝试使用编辑器完成来完成多文件作业或使用重型代理来完成小附件。
- 释放代理。范围狭窄且没有“计划优先”的代理任务会产生未经审查的变化。
- 放宽人工智能的验证门槛。 “人工智能做到了，让我们快速前进”是最危险的例外；每个人的门都是一样的。
- 每次都手动给出上下文。不将项目规则写入永久说明文件会产生不一致和重复。
- 将 CI 机器人的批准误认为是人类的批准。机器人是一个过滤器；负责任的人类批准是强制性的。
总之
AI 编码工具主要分为四大类：编辑器补全、聊天助手、CLI 代理和 CI 自动化。掌握是将任务与正确的工具和正确的自主程度相匹配；随着自主权的增加，控制权也随之增加。为工具提供持久的项目背景，对多文件代理实施“计划优先”原则，并通过与人类变更相同的验证门来传递人工智能变更。个人技能；将其转变为一个基于批准的工具列表、验证门、透明度和责任明确性的团队系统。人工智能是端到端的速度倍增器；签署并提供账目的人始终是有能力的人。
应用任务
列出下周你要完成的三项实际任务。为每个车辆使用“任务与车辆匹配决策”模板，以证明您将选择哪种车辆类别以及哪种自动驾驶级别。然后，按照“计划优先”的原则，为 CLI 代理（或聊天助理）运行一项狭窄的任务：批准计划、执行计划、运行测试并像人工 PR 一样审查更改。最后，为你的团队起草一份 5 点“人工智能使用规则”（批准的工具、数据规则、验证门、自主限制、责任）。
清单
- [ ] 我可以区分人工智能编码工具类别以及每种工具的最佳位置。
- [ ] 我将任务映射到正确的车辆类别和适当的自主级别。
- [ ] 我为工具提供了永久的项目上下文（指令文件）。
- [ ] 我对 CLI 代理应用狭窄的范围和“计划优先”原则。
- [ ] 我通过与人类更改相同的验证门来传递人工智能更改。
- [ ] 我主张在团队层面采用经过验证的工具、数据规则、透明度和问责框架。
模块考试
1. 编码助手的底层大语言模型在生成代码时实际上做了什么？
- A) 根据给定上下文有规律地预测最可能的延续 ✔
- B) 通过实际编译和运行代码来保证正确的结果
- C) 它实时扫描整个互联网上的代码并复制最准确的代码。
- D）像人类工程师一样理解代码的逻辑并理解意图
澄清：LLM 并不像人类一样“理解”代码；它根据从大量文本和代码中学习到的模式，生成给定上下文最有可能的延续。因此，输出的质量直接取决于您给出的上下文和指令的质量，并且每个输出都必须经过验证。
2. 当人工智能令人信服地编造出一个不存在的函数或库时，你怎么称呼它？唯一真正的解药是什么？
- A) 这称为编译错误；解药是更强的装备
- B) 这称为幻觉；解决方法是验证代码和使用的每个 API ✔
- C) 这称为回归；解决方法是重新启动模型
- D) 这称为上下文溢出；解决办法是缩短提示
描述：这称为幻觉，会导致软件中最昂贵的错误之一。唯一真正的解药是验证：确认使用的每个函数、API 和包确实存在并且代码有效。模型的自信语气并不能证明其准确性。
3. 使用人工智能生成代码时，哪种方法最能提高输出的质量和一致性？
- A）通过说“写给我”来发布模型，而不提供任何上下文
- B) 尽可能写出最长且花哨的提示
- C) 指定并给出输入/输出契约、边缘情况、版本和样式的示例 ✔
- D) 不读取生成的代码，直接组合
说明：确定函数的输入/输出类型（契约）、边缘情况、语言/版本和样式约束并向模型提供示例可以实现从预测到精度的转变。无上下文的“写给我这个”请求每次都会生成不同的代码，并且通常会绕过边缘情况。
4. 当用AI探索国外代码库时，函数名称可能是“validateAndSave”，但AI摘要可能不正确。什么是正确的做法？
- A) 对 AI 摘要充满信心，因为名称是不言自明的
- B) 不读直接改变函数
- C) 仅通过查看函数名称来决定
- D) 将 AI 描述视为假设，并在代码中逐行验证关键主张 ✔
解释：人工智能可能会查看代码中的名称并告诉你“它看起来像在做什么”，但实际上逻辑可能不同（甚至相反）。所以AI的解释是一个假设；关键索赔，特别是那些涉及安全、权力或资金流的索赔，应在相关线路上进行目视验证。
5. 在人工智能辅助代码审查中说“人工智能看起来很清楚”的最大危险是什么？
- A) AI可能会产生漏报；真正错过的错误会产生虚假的信心✔
- B) AI审稿速度太慢，浪费时间
- C) 团队听不懂，因为人工智能只用英语评论
- D) PR 不会收敛，因为 AI 总是过度解释
解释：人工智能会产生误报（标记不存在的问题）和漏报（遗漏真正的错误）。假阴性是沉默的；最危险的错误是那些评论中根本没有提到的错误。所以人工智能是第一个过滤器，而不是批准；合并的决定属于负责人。
6. 当你只给AI代码和打印测试时，发生的最阴险的陷阱是什么？
- A）人工智能总是编写太多测试并使代码库膨胀
- B) AI 测试代码当前（可能是错误的）行为是否“正确”并修复错误 ✔
- C）AI在编写测试时自动删除代码
- D）人工智能不仅为快乐路径编写测试，而且总是为边缘情况编写测试
说明：人工智能倾向于查看代码并编写测试当前行为的断言。如果代码从一开始就是错误的，人工智能会将这种错误行为修复为“正确”。因此，测试的期望应该根据所需的规则（规范）来编写，而不是根据代码当前的输出来编写。
7. 当使用人工智能调试错误时，什么最决定假设的准确性？
- A) 提示写得有多礼貌。
- B）这个问题被重复问了多少次
- C) 向模型提供的证据质量：完整的错误消息、堆栈跟踪、输入和预期行为 ✔
- D) 代码是用什么颜色主题编写的？
说明：AI 不会像您那样看到错误；他只知道你给他的证据。给定完整的错误消息、堆栈跟踪、触发输入和预期行为，模型会枚举真实的可能性；如果没有证据，它就会做出猜测（幻觉）并引导你走上错误的道路。
8. 将生产日志交给AI分析之前最关键的一步是什么？
- A）按原样粘贴日志，覆盖一整天
- B) 首先将 log 转换为大写
- C) 按字母顺序排列日志行
- D) 屏蔽个人数据和秘密并仅提供相关窗口 ✔
描述：原始生产日志包含 IP、电子邮件、会话 ID、令牌，有时还包含公开秘密。将它们粘贴到人工智能工具而不屏蔽它们是严重侵犯隐私的行为。此外，日志应该被过滤到一个狭窄的时间窗口；但首要任务是清理敏感数据。
9. 如果人工智能在日志分析中说两个事件“同时”发生，并声明其中一个为根本原因，该怎么办？
- A) 将相关性视为因果关系，并使用指标和代码验证主张 ✔
- B）接受确定的原因，因为人工智能建立了时间关系
- C) 立即重新启动第一个被指控的组件
- D) 彻底删除日志并重新收集
说明：日志分析中最常见的陷阱是混淆相关性与因果关系。 AI建立的时间关系是线索，而不是证据。真正的因果关系需要时机、机制，如果可能的话，还需要可重复性；必须使用指标和代码来验证声明。
10. 使用人工智能进行重构时不可协商的黄金法则是什么？什么可以保证它？
- A) 代码应该更短；行数保证了这一点
- B) 行为没有改变；捕获当前行为的测试可确保这一点 ✔
- C) 代码包含较多注释；人工智能保证了这一点
- D) 一次性重写整个文件；代理保证这一点
说明：重构是在不改变代码外部行为的情况下改进代码的内部结构；黄金法则是行为保持不变。确保这一点的是测试：在每个步骤之后设置并运行一个测试网，该测试网在更改之前捕获当前行为。没有测试网的重构是一场赌博。
11. 文档生成中的哪一层是人工智能无法识别且构成危险的？
- A) 如何运行安装步骤
- B) 函数的参数列表
- C) 说明“为什么”这样做出设计决策的理由 ✔
- D) 代码是用什么语言编写的？
描述：人工智能可以从代码中提取“什么/如何”层（函数做什么，如何设置）；但它无法知道“为什么”层（决策的设计原理、限制值的原因）。编造的“理由”比没有理由更危险；代码所有者必须添加此层。
12. 如果开发人员想要将包含实时 API 密钥的配置文件粘贴到未经批准的 AI 工具中，同时解决紧急错误，该怎么办？
- A) 为了速度，按原样粘贴文件，然后删除聊天记录
- B) 在文件末尾添加“机密”注释并发送
- C) 保留密钥并仅更改文件名
- D) 删除/掩盖秘密并仅提供必要的非敏感上下文 ✔
披露：绝不能以未经批准的方式泄露秘密、个人数据和机密资产；紧急情况并不能暂停这条红线。正确的方法是首先提取/掩盖秘密，然后仅提供必要的、非敏感的上下文。如果秘密仍然泄露，首先要做的就是立即转动钥匙。
13. AI 生成的代码通过测试并在生产中运行。这是否证明代码是安全的？
- A) 否； “工作”并不意味着安全，安全需要单独的身份验证层✔
- B) 是；根据定义，通过测试的代码是安全的
- C) 是；在生产中运行它消除了所有漏洞
- D) 否；但只有当代码速度很慢时，安全性才重要
澄清：“工作”与“安全”不同。即使代码存在SQL注入等漏洞，也能通过测试并顺利运行；仅当攻击者发现该漏洞时，该漏洞才会被暴露。因此，除了准确性之外，面向安全的审查和扫描（例如 SAST）还应作为单独的层来执行。
14. 将多文件任务交给 CLI 代理（可以修改文件和运行命令的自主工具）时，最安全的原则是什么？
- A）告诉代理“改进这个模块”并给予充分的自由
- B) 给出狭窄的范围和验收标准，首先要求制定计划，批准计划，逐步实施，然后运行测试 ✔
- C) 直接合并agent的所有变更而不进行review
- D) 给予代理不受限制地访问生产环境和机密数据
解释：随着自主权的增加，控制权也应该增加。给代理商一个狭窄的范围和明确的验收标准，首先要求不做任何修改的方案，批准方案，然后逐步实施，每一步都进行测试；它可以防止广泛的、不可审查的、需要回滚的更改。
15. 谁对安全关键软件（例如支付或身份验证）中人工智能生成的代码承担责任？
- A) 由于代码来自AI，因此位于车辆提供商处
- B）如果人工智能已经充分发展，那么没有人做到；无需验证
- C) 检查、组装和分发代码的团队/工程师； AI 不能取代同意 ✔
- D）只有写提示的人，而不是审阅提示的人
描述：AI是速度倍增器和蓝图生成器；无法承担责任。生产中的代码引起的任何错误、漏洞或违规行为由审查、组装和分发该代码的团队负责。在安全关键领域，人工智能输出在任何情况下都不能替代合格工程师的审查和批准。