收益：
- 能够通过内联完成将聊天模式映射到更正任务类型
- 能够编写强大的生产提示，包括输入/输出合同、边缘情况和风格约束
- 能够在合并之前验证生成的代码和任何新提议的依赖项
开发人员与人工智能的第一个接触点通常是自动完成——一种在您键入时建议下一行的功能——或者在聊天窗口中说“键入该功能”。它们都使用相同的引擎，但需要不同的规则。在本单元中，我们将代码生成从随机“写下来”转变为输出可预测和可验证的工程步骤。
我们的目标是将人工智能从加速打字机的工具转变为在您设置的限制内工作的学徒。受良好指导的学徒可以节省时间；没有指导的学徒会造成混乱，你必须稍后清理。
两种使用模式：内联完成和聊天
当您在编辑器中输入内容时，内联补全就会发挥作用；您输入函数签名或注释行，它会建议其余部分。它对速度很有帮助，但它的上下文很窄：它只能看到邻近区域中的代码。这就是为什么当你在评论中清楚地写下你的意图时效果最好。例如， //validate user email, throw ValidationError if invalid comment 显着改进了下面的建议。
聊天模式适用于较大的结构化任务：“向此类添加分页”、“提取该服务的接口”。在这里你可以奢侈地赋予角色、背景和形式。一般规则是：完成小而流动的任务，对话处理需要思考和结构的任务。
提示：不要盲目接受“Tab”的补全建议。阅读一下建议的行；不正确的变量名或反转的条件最常从这里泄漏。
将意图转化为代码的步骤
- 定义合同。该函数的输入、输出和错误行为是什么？就像“获取电子邮件，如果有效则标准化，如果无效则抛出错误”。
- 说明限制条件。不使用外部依赖？具体的风格指南？有性能限制吗？
- 举个例子。输入-输出对（“ali@x.com→有效，ali@→错误”）将模型对意图的理解从预测转向精确。
- 要求小块。一种职能，一种责任。然后继续下一个。
- 读取并运行生成的代码。编译+快速手动尝试是最便宜的保证步骤。
三个迷你箱
案例 1 — 评论驱动的生产提高了准确性。开发人员首先请求了一个空主体的日期解析函数，并在 3 轮后得到了正确的结果。在第二次尝试中，当我用 4 行注释（接受的格式、时区规则、错误条件）定义函数并请求它时，第一轮中有效的代码就出现了。同一型号，同一天；区别只是意图的清晰度。
情况 2 — 不指定版本的成本很高。一个团队在为 Node.js 生成的代码中使用基于回调的旧 API 来替换 fs.promises 方面遇到了困难。当提示中添加“使用 Node 20、ESM、async/await”这一行时，生产第一次跟随项目；平均花费 12 分钟的纠正时间被重置。
案例 3 — 样板代码的实际收益。微服务需要 6 个新的 DTO（数据传输对象 - 一种在层之间传输数据的简单数据类）及其验证规则。原来大约90分钟的手工工作，通过人工智能制作和审核后，减少到35分钟；由于代码重复率高且模式清晰，人工智能在这里发挥了最有效的作用。
四个可复制模板
基于契约的函数生成：
角色：您是一名勤奋的 {{language}} 开发人员。函数契约：- 名称：{{name}}- 输入：{{类型及其含义}}- 输出：{{类型及其含义}}- 错误状态：{{何时抛出/返回什么}}约束：{{无外部依赖项/样式/性能}}示例：- {{input_1}} -> {{output_1}}- {{entry_2}} -> {{error_2}}先给出签名+简短计划，然后给出代码。编写测试，只是功能。
要匹配现有样式（适应代码库）：
以下是我们项目中的示例函数；在这里学习命名、错误处理和注释风格。使用相同的风格为 {{new_task}} 编写一个函数。示例：{{当前代码}}
从骨架到填充（存根→实现）：
根据注释中的TODO填写下面的函数骨架。更改签名和返回类型。不要创建不存在的辅助函数；如果有必要，请告诉我“需要这个帮手”。 {{骨架_kod}}
替代应用程序比较：
为 {{task}} 提供 2 种不同的实现：(a) 优先考虑可读性，(b) 优先考虑性能。在每句话下面写下 1 句话“什么时候最好”。
弱提示/强提示
弱：“给我写一个电子邮件验证功能。”
强：“TypeScript 5，仅限标准库。编写 isValidEmail(input: string): boolean。修剪空格，使其不区分大小写，a@b.co 有效，a@, @b.co，空字符串无效。如果要使用正则表达式，请不要过于复杂；添加 2 行注释。”
强大版本；返回语言、版本、签名、边缘情况和样式约束。因此，生成的代码既可以工作，又适合您的项目。
方法
何时使用
注意
内联完成
流动中的小插入件
请勿在未阅读建议的情况下接受该建议
聊天中基于合同的生产
新函数/类
给出示例和边缘情况
按款式来样生产
添加到现有代码
选择当前示例代码
骨架馅
签名固定，正文空白
更改签名
代码重复和依赖陷阱
人工智能经常推荐一个新的库，以使其工作更轻松。有时这是准确的，有时它会为您的项目添加不必要的依赖项或建议一个不存在的包（幻觉）。规则：您确认每个新的依赖项。在未验证该包是否实际存在、是否得到维护以及是否具有适当的许可证的情况下，请勿将其添加到项目中。大多数时候，项目中已有的助手比新包更好。
注意：查看 AI 建议的导入行。不存在的包名称（也可能类似于称为“错字抢注”的假包）既会破坏编译，也会带来安全风险。
常见错误
- 具有由模型确定的签名。如果不修复输入/输出类型，则每次生产都会带有不同的签名，并且集成会变得困难。
- 更不用说边缘情况了。空输入、null、负数、非常大的值 - 如果您不指定这些，模型会写入“快乐路径”，跳过边缘。
- 结合建议而不进行测试。看起来有效的代码并不意味着它有效。
- 接受不必要的依赖。为一句台词添加整个库会产生技术债务。
- 风格不一致。与项目其余部分不同的命名和错误处理使得代码库不完整。
综上所述
当您将意图转化为清晰的合同时，代码生成功能非常强大。对小型流内任务以及在对话中建立结构的任务使用内联完成。您指定输入/输出类型、边缘情况、版本和样式；给出模型的例子；验证每个新的依赖项；并运行并阅读生成的每一篇文章。人工智能在公式化、重复性代码中的回报最好——在你设置的限制内就地运行它。
应用任务
从您的项目中选择一个您需要编写的实际小函数。首先使用“基于契约的函数生成”模板将其打印到 AI，给出输入/输出类型、两种边缘情况和样式约束。编译生成的代码并使用两个不同的输入进行尝试。然后再次询问相同的函数，这次在没有任何上下文的情况下“写给我这个”，并逐行比较两个输出：遗漏了哪些边缘情况，需要多少次更正？
清单
- [ ] 我知道在哪里使用带有内联完成功能的聊天模式。
- [ ] 我确定函数生成中的输入/输出契约和边缘情况。
- [ ] 我已经养成了在提示中添加语言和版本信息的习惯。
- [ ] 我在组装之前编译并测试每个生产的部件。
- [ ] 我通过验证 AI 提出的每个新依赖关系的存在性和必要性来确认其存在性和必要性。
- [ ] 我检查生成的代码是否与项目的风格相匹配。