背景痛点：提示词写得越随意，返工越频繁
第一次把 GitHub Copilot 请进 IDE 时，我以为'会说话就能写代码'。结果三天后，同一段逻辑被它反复生成三种完全不同的写法：变量命名一会儿匈牙利、一会儿驼峰；边界条件时而 <= 时而 <；最离谱的是把 async/await 和 .then 混在一个文件里。问题根源不在模型，而在我的提示词——太模糊、太短、没有上下文。总结下来，开发者最容易踩的坑集中在三点：
- 任务描述像'帮我写个排序'这种一句话，模型只能猜数据规模、猜稳定性需求，结果当然随缘。
- 上下文缺失，Copilot 只能看到当前打开的文件，对项目里已有的工具函数、类型定义、测试风格一无所知，于是'重复造轮子'或'风格打架'。
- 缺少负例，没告诉它'不要怎么做'，导致生成代码里悄悄混入废弃 API 或安全漏洞。
想提升效率，第一步是把提示词当成'接口文档'来写：输入越严谨，输出越省心。
技术选型对比：三种提示策略谁更适合你
我把过去半年在团队里试过的策略归成三类，用同一个小需求——'把 CSV 字符串转成嵌套 JSON'——做横向对比，结论一目了然。
| 策略 | 提示词长度 | 生成耗时 | 一次通过率 | 维护成本 | 适用场景 |
|---|---|---|---|---|---|
| 零提示（直接空行触发） | 0 字符 | 1.2 s | 20 % | 低 | 临时脚本、一次性代码 |
| 极简提示（一句话） | ≈30 字符 | 1.4 s | 35 % | 低 | 个人小工具，对风格不敏感 |
| 结构化提示（上下文 + 示例 + 约束） | ≈400 字符 | 2.1 s | 85 % | 中 | 业务主干、长期维护模块 |
显然，结构化提示在'一次通过率'上碾压前两者，多花的 0.7 s 换来少返工一小时，ROI 极高。后文所有实践均围绕'结构化'展开。
核心实现细节：把提示词拆成四段模板
我把常用模板固化成四段，顺序别乱，Copilot 的注意力会按段落递进：
Negative Rules
用'DO NOT'显式屏蔽脏代码。
// DO NOT use sync fs API, DO NOT introduce external deps, DO NOT mutate input.
Positive Example
给一段最短可行样本，让模型'照抄'风格。
// Example: // Input: "1,Alice,0\n2,Bob,1" // Output: [{id:1,name:"Alice",children:[{id:2,name:"Bob",children:[]}]}]
Task
用'给定…输出…'的句式，把输入输出类型写死，减少自由发挥。
// Task: Given a CSV string with headers `id,name,parentId`, // return a nested JSON array where each node has `children: Node[]`.
Context
先给模型'地图'：项目语言版本、主要框架、已封装的工具函数。
示例：
// Runtime: Node 20, ESM, no TypeScript // Utils: lodash-es, [email protected], dayjs // Existing: parseCsv() -> Promise<Record[]>, formatDate() -> string
