产品经理用Cursor自动生成技术文档：规则文件与提示词实战指南

产品经理用Cursor自动生成技术文档，这段时间在我们团队内部已经成了默认流程。你可能听到“Cursor”第一反应是“AI编程工具，跟我产品经理有什么关系”，但实际上，它是目前最合适做“需求语言到工程语言”翻译的AI编辑器。配合一套开发规范规则文件和UI设计规则模板，它能快速生成接口文档、数据字典、状态机、权限矩阵、界面设计说明，而且是按你们团队的开发规范来写，不是市场上泛泛的AI套路文。这篇文章我会把完整做法拆开，包括规则文件怎么写、提示词怎么喂、生成后怎么查漏，以及我踩过的坑。适合产品经理、技术文档工程师，也适合不想在开发评审会上被追问“字段类型到底是什么”的任何人。

1. 先搞明白：产品经理用Cursor写技术文档，到底卡在哪

1.1 从“PRD语言”到“开发语言”，中间隔着一层工程约定

我说个常见场景。产品经理花了两天写PRD，流程图、原型图都齐了，结果评审的时候后端问了一句：“用户申请退款这个接口，你是准备一次提交还是先创建草稿再提交？状态字段用字符串还是整数？幂等怎么做？”当场就卡住了。PRD写的是业务逻辑，但开发要的是一套工程决策，两者中间隔着一条巨大的沟。

这条沟不是产品经理不努力，而是因为“技术文档”本来就不是PRD的翻版。PRD可以说“用户点击申请退款”，技术文档却要把这句话拆成：接口路径、请求参数、返回结构、状态流转、错误码、权限点、幂等策略、埋点事件。任何一个字段没写清楚，开发就得自己脑补一个，等上线后跟设计稿对不上，再回来吵。

所以我把这件事总结成六个字：翻译损耗太大。产品经理不是不会写字，而是不掌握团队的“工程约定”。这些约定包括URL怎么命名、错误码怎么编号、金额字段用decimal还是int、时间字段用时间戳还是字符串、分页参数叫page还是offset、状态机怎么定义异常分支。这些内容很少有人系统总结，通常散落在老开发脑子里。

解决思路不是让每个产品经理去学写代码，而是把这些“工程约定”沉淀成一个规则文件，让Cursor在生成文档的时候严格遵守。Cursor本身是AI编程工具，但它的能力边界不只是写代码。它能读我放在项目目录里的规则，能读取仓库里的上下文，能在同一个工程文件夹里反复生成、修正、对照。这几件事合在一起，恰好能解决“PRD语言到开发语言”的翻译问题。

1.2 Cursor能帮产品经理把“模糊需求”变成“初版技术文档”

我第一次试的时候，做法很简单：新建一个文件夹，把需求描述丢给Cursor，让它写接口文档。结果它写得还挺像回事，表头完整、字段类型齐全，但仔细一看，很多字段是它自己编的，状态枚举跟业务对不上，错误码也没有按团队规则来。这个问题的根源不是Cursor不行，而是我没有给它“约束”。

后来我把开发规范整理成规则文件放到.cursor/rules目录，再让它生成，效果立刻不一样。为什么不是直接用网页版ChatGPT？因为Cursor是编辑器形态，规则文件能随项目走，团队其他人拉下仓库就能复用。它还能通过Codebase读取现有代码，帮你做文档与代码的一致性检查。这些能力对产品经理来说，等于有了一个懂开发规范、还能翻代码库的“初稿撰写助手”。

你不能指望它一次性输出完美文档，但你可以让它把一张白纸填充成80分的初稿，再花半小时人工修正，而不是自己对着空白文档憋一整天。我实际体验下来，生成一份包含数据字典、接口文档、状态机、权限矩阵的技术文档草稿，过去至少需要两个小时，现在十分钟就能有一版能拿去评审的初稿。

这套工作流可以概括成六步：建文档仓、放规则文件、写需求输入、让Cursor生成草稿、人工自检、找开发校准。接下来我会一步步讲清楚。

2. 搭建规则库：让Cursor一出手就符合开发规范

2.1 先搭一个“产品规范仓库”，而不是在聊天框里裸写

我知道很多人用AI的习惯是打开网页，把需求粘贴进去，让它写，写完之后复制到文档里。如果你只是想生成一个临时PRD，这样没问题。但如果你要生成的是“符合开发规范的技术文档”，必须把整套规范放到一个固定位置，让每次生成都能稳定引用。

我建议建一个叫product-specs的仓库，用Git管理，目录结构大概这样：

product-specs/ ├── .cursor/ │ └── rules/ │ ├── tech-doc-rules.mdc │ ├── api-doc-rules.mdc │ └── ui-design-rules.mdc ├── templates/ │ ├── api-doc-template.md │ └── ui-design-template.md ├── drafts/ │ └── 2025-06-order-refund/ │ ├── requirement.md │ ├── api-doc.md │ ├──>--- description: 产品技术文档通用规范，所有Markdown文档默认遵循 globs: ["*.md"] --- # 通用技术文档规则 1. 语言与术语 - 默认使用简体中文，技术术语首次出现时保留英文缩写，如订单状态（Order Status）。 - 禁止使用“等等”“大概”“可能”等模糊词；不确定的内容必须明确标注 [TBD]，并写出待确认的问题清单。 2. 文档结构 每篇技术文档必须包含： - 背景与目标 - 名词解释 - 功能/流程描述 - 接口或数据处理方案 - 异常与边界处理 - 权限说明 - 埋点说明（如有） - 变更记录 3. 字段表格约束 - 所有字段描述必须用 Markdown 表格，禁止写成散文。 - 表头必须包含：字段名、类型、必填、默认值、说明/枚举。 - 金额字段必须注明单位、精度、是否允许负数。 - 时间字段必须注明格式，如 yyyy-MM-dd HH:mm:ss、时间戳。 4. 状态机约束 - 必须描述正常路径、拒绝路径、取消路径、超时路径、异常恢复路径。 - 每个状态变更必须包含：触发条件、前置状态、后置状态、需执行的系统动作。 5. 错误码约束 - 错误码由“模块缩写_编号”组成，如 ORDER_4001。 - 必须包含 code、message、用户端提示、触发条件。 - 未确认的错误码先写 TBD，禁止编造已有错误码。 6. 输出要求 - 用户要求生成文档时，先输出“文档目录”，确认后再写详细内容。 - 在文档末尾追加生成元信息：生成时间、使用的模型、规则版本、待人工确认项。

写这个文件的时候，有个关键点：不要写成“文档要尽量详细”这种废话，要写成像“字段表必须包含哪些列”这种可判定的规则。AI在生成时能不能遵守，取决于它能不能判断自己是否违反了规则。如果规则本身模糊，生成结果也会模糊。

团队如果有自己的特殊约定，直接追加进去。比如Java后端习惯把时间字段叫createTime，数据库层用datetime；比如错误码统一用E_开头而不是ORDER_；比如接口路径必须带/api/v1前缀。这些内容放得越细，生成结果越接近团队真实风格。

2.3 接口文档规则：让AI产出开发能直接评审的API描述

通用文档规则管的是“所有文档的写法”，接口文档还需要一套更细的规则。把它单独拆出来，是因为接口文档是所有技术文档里最容易翻车的一类。AI特别容易漏掉请求头、漏掉错误码、把响应结构写得跟实际工程不一致。

我建议创建一个.cursor/rules/api-doc-rules.mdc：

--- description: 接口文档规范，适用于所有API设计文档 globs: ["**/api-doc.md", "**/*api*.md"] --- # 接口文档规则 1. 每个接口必须依次包含以下小节： - 接口名称与摘要 - URL、Method、Content-Type - 请求头（含认证方式、traceId等） - 请求参数：Query / Path / Body 分别列出 - 响应结构：成功示例、分页结构、字段说明 - 业务错误码与HTTP状态码映射 - 幂等性说明 - 权限与频控说明 2. 参数表必须包含：参数名、类型、是否必填、默认值、校验规则、说明。 例如：uid: string, 必填，“用户ID，对应 users.id” 3. 响应统一封装为： { "code": 0, "message": "success", "data": ... } code 为 0 表示成功，业务错误码以 ORDER_ 开头。 4. 分页参数统一使用 page（从1开始）、pageSize（默认20，最大100）。 分页响应包含 list、total、page、pageSize。 5. 所有涉及金额、状态的接口，必须在文档中标注幂等策略： 例如退款接口需要 powerToken 或 requestId 防重。 6. 禁止生成与典型REST习惯不符的语义： 例如“查询用POST”时必须有明确理由；删除/修改类接口必须声明是否需要权限和二次确认。

这个文件我特别推荐把“响应统一封装结构”写死。不同团队可能有自己的统一返回体，有的是{code, message, data}，有的是{ret, msg, result}。如果不写进规则，Cursor默认会用最常见的结构，但这可能跟你们后端框架不一致。

另外，接口文档规则还要解决一个问题：AI总是喜欢把“错误码”列得特别全，动不动就给你一百行，但很多错误码是它编的。我在规则里加了一句话“未确认的错误码先写TBD，禁止编造”，这一条非常有用，能减少大量对空话错误码的返工。

2.4 规则文件如何被Cursor加载

文件放在.cursor/rules下不一定每次都会自动读取。Cursor读取规则有三种常见方式，我在实际操作中都会用到。

第一种是按globs自动匹配。比如.mdc文件里写了globs: ["**/api-doc.md"]，当你打开或生成api-doc.md时，Cursor会自动把这条规则加入上下文。第二种是在聊天或Composer中手动引用，输入@Rules可以看到项目里的规则列表，也可以直接@文件路径把某个规则文件作为附件喂给AI。第三种是在命令面板里搜索“Rules”查看当前生效的规则，确认是不是漏加载了。

改完规则文件后，如果觉得Cursor没有按新规则执行，最好重启一下窗口。这个动作很基础，但很多人忽略，结果以为是规则没写对，实际上是缓存没刷新。还有一点，规则文件不一定要等Cursor官方推荐的文件路径，你可以把团队的规范文档也放在.cursor/rules目录中，只要它有.mdc后缀，并且写清楚适用范围，就能被当作规则上下文使用。

3. 实操演示：把一段需求变成一套技术文档

3.1 需求输入的五个要素

很多人用AI生成文档效果不好，第一反应是“AI不行”，但九成情况是需求输入写得不行。如果你只丢一句“帮我写一个退款文档”，AI只能给你一个“百度百科式”的通用模板。想让输出贴近项目，输入至少要包含五个要素。

业务背景，一句话说清楚这是什么场景。角色，说明有哪些人使用，比如买家、客服、财务、系统。核心流程与分支，正常路径之外一定要写取消、超时、失败、重试。关键字段与枚举，哪怕你只给业务术语，也能让AI少编造一些。非功能要求，比如埋点、权限、操作日志、无障碍、性能。

这些不必写成完美PRD，只需要像跟同事讨论需求一样，把关键信息铺开。越零碎没关系，目标是把你的输入变成“上下文”，AI需要这些上下文才能输出有业务味道的文档。

我经常直接打开一个空白requirement.md，把产品想法用bullet点列出来，然后把文件塞给Cursor。这样比在聊天框里粘贴一大段要清晰，因为文件可以挂在项目目录里，后续生成所有文档都能引用。

3.2 完整Prompt示例：订单退款

我给一个我常用、效果不错的输入样例。这是一段简化版的订单退款需求：

场景：用户在订单详情页申请退款 角色：买家、售后客服、财务、系统 规则： - 仅限已支付且未被删除的订单 - 退款金额不能超过订单实付金额 - 退款原因枚举：拍错/少发/质量问题/不想要/其他 - 退款原路退回支付账户 流程： 1. 用户提交申请 -> 状态“待审核”，通知客服 2. 客服审核：通过 -> “待退款”；拒绝 -> 填写拒绝原因，状态“已拒绝” 3. 待退款超过48小时未处理，系统自动退款 4. 自动退款调用第三方支付平台原路退回 5. 成功 -> “退款成功”；失败 -> “退款失败”，用户可以重新申请 6. 退款成功后订单标记“已关闭”，发送站内信

然后给Cursor下指令，我习惯写成这样：

请严格遵循 .cursor/rules 下的 tech-doc-rules.mdc 和 api-doc-rules.mdc，基于以下需求生成技术文档初稿： 1. 数据字典（order_refund 相关字段） 2. 接口文档（退款申请、审核、查询、重试） 3. 状态机与状态流转表 4. 错误码表 5. 权限矩阵 需求原文： 【把 requirement.md 内容粘贴进来】

这里有个细节：我会在白名单里点名规则文件，而不是笼统说“遵守所有规则”。因为Cursor一次能参考的上下文是有限的，当项目规则很多时，明确告诉它用哪几个文件，效果比让它自己判断稳定得多。

3.3 生成结果应该长什么样

按照上面的Prompt，Cursor生成的内容大致是这些。数据字典表：

接口列表：

状态机表会列当前状态、触发事件、前置状态、后置状态、系统动作。错误码表会生成ORDER_4001这类规则内定义的格式。如果生成结果没有满足要求，直接让它补：把状态机补齐异常分支、错误码按ORDER_开头、金额字段标注精度。这类指令越具体，第二次生成越准。

3.4 生成后的文档自检清单

Cursor生成完文档，我不急着发出去，会先过一遍自检清单。这也是我要专门写出来的原因：AI生成的文档最大的风险不是“写得不好”，而是“看起来很好但全是坑”。如果你不检查，很容易把幻觉字段发到评审里，被开发当众指出，那比没有文档还尴尬。

我的自检清单大致长这样：

• 每个接口是否都有URL、Method、请求参数、响应示例和错误码？
• 参数表是否包含类型、必填、默认值、校验规则？
• 状态机是否覆盖正常路径、拒绝路径、取消路径、超时路径、失败重试？
• 错误码是否符合团队的编码规则，未确认项是否标注了TBD？
• 权限矩阵是否覆盖页面、按钮、API三个层级？
• 金额、时间、文件大小等字段是否明确单位与精度？
• 文档里是否还存在“大概”“可能”“等等”这样的模糊词？

自检的时候要允许自己改文档，而不是让AI反复生成。修改犹豫不决的地方，直接标注成TBD，留给开发评审时一起确认。

3.5 用Codebase反向校验文档与代码一致性

这是我认为Cursor比普通聊天AI强很多的一点。如果你们团队允许产品经理查看后端代码仓库，你可以用Cursor打开后端项目，启用Codebase索引，然后问它：请根据实际代码，对比订单退款接口的实现，检查api-doc.md中的字段名、状态枚举、错误码是否一致。

实际效果取决于代码质量和注释情况，但即便只能查出50%的问题，也比人工翻代码快很多。我通常会把这一步交给开发配合执行，让开发在自己熟悉的后端仓库里跑一遍，把结果返回到文档评审里。

用Codebase校验时注意：一定要给Cursor明确的“对比对象”，比如指定某个Controller文件、某个状态枚举类，而不是笼统说“检查代码”。否则它会优先参考网上通用知识，而不是你们真实的代码实现。

4. UI设计规则模板：让AI输出界面规范而不是散文

4.1 设计Token规则：颜色、字体、间距、圆角

UI设计规则模板是很多人忽略的一块。大家总以为技术文档就是接口文档，其实现在前后端分离，前端设计规范同样是技术文档的一部分。Cursor生成UI设计文档时，最常见的毛病是写“按钮建议使用品牌蓝色”，听着没错，但前端拿到这种文档没法直接写代码，因为颜色、字号、间距都依赖设计系统的Token。

所谓设计Token，就是给设计属性起语义化名字。比如主色不叫“蓝色”，叫--color-primary；危险色不叫“红色”，叫--color-danger；页面背景不叫“浅灰”，叫--color-bg-page。如果你在规则里要求AI“所有颜色引用Token，禁止写死色值”，它生成的UI规范就一下子有了工程可落地性。

同样的逻辑适用于字体、间距和圆角。字体不用“小一点”“大一点”，而是定义--font-size-base: 14px、--font-size-caption: 12px。间距用4px步进单位，常用8、12、16、24、32。圆角分别为按钮6px、卡片12px、弹窗16px、输入框8px。有了这些基准，AI才能生成一套前后端都能照着实现的UI文档。

4.2 组件与状态规则

UI设计模板里第二重要的是组件状态。设计稿里画了按钮，但开发真正关心的是这个按钮在不同状态下显示什么、是否可以点击、点击后有没有反馈。规则里至少要覆盖按钮、输入框、表格、弹窗、空状态、Toast几类高频组件。

按钮要有默认、悬停、按下、禁用、加载五种状态，分层级分为主按钮、次按钮、危险按钮、文本按钮。输入框要规定标签位置、占位符、错误提示位置、获取焦点时的状态。弹窗要规定标题、正文、底部操作区，以及危险操作是否二次确认。空状态要包含标题、说明、行动按钮，不能只画一个插画。

我写规则文件时，会把每个组件按“结构、状态、行为”三块描述。结构是长什么样，状态是交互变化，行为是点击后发生什么。这样AI生成的UI规范就不会是一堆形容词，而是能直接指导前端开发的行为说明。

4.3 无障碍和暗黑模式规则

无障碍规则是UI文档里最容易被漏掉，又最能体现专业度的部分。如果产品面向C端，无障碍不过关，上线审计很可能出问题。即使内部系统，也建议在规则文件里加几条强制项。

正文与背景的对比度至少4.5比1；可点击区域最小44乘44像素；键盘焦点样式要明显，不能依赖鼠标悬停；错误提示不能只靠颜色差异，必须配合文字或图标。暗黑模式不能通过简单反转颜色实现，而是用语义Token在不同主题下映射不同色值，层级通过背景明暗和阴影表达，而不是大面积纯黑。

这些规则写进UI规则文件后，Cursor在生成界面说明时会自动带上“焦点顺序”“对比度要求”之类的内容，这份文档拿到设计评审里就会好看很多。

4.4 UI规则文件模板示例

下面是我项目里在用的ui-design-rules.mdc，你可以直接参考：

--- description: UI设计规则，输出界面规范时强制使用 globs: ["**/ui-notes.md", "**/design*.md", "**/*ui*.md"] --- # UI 设计规则 1. 颜色 - 所有颜色引用语义化Token，格式如 --color-primary、--color-success、--color-danger、--color-bg-page、--color-text-primary。 - 禁止在文档中直接写死十六进制颜色。 2. 字体与字号 - 正文 14px / 行高 22px - 辅助说明 12px / 行高 18px - 标题层级使用 20px / 18px / 16px - 数字与英文使用等宽数字（Tabular Numbers） 3. 间距 - 使用 4px 为步进单位，常用：4、8、12、16、24、32、48。 4. 圆角 - 按钮 6px，卡片 12px，弹窗 16px，输入框 8px。 5. 按钮 - 必须定义 default、hover、active、disabled、loading 五种状态。 - 分层级：主按钮、次按钮、危险按钮、文本按钮。 6. 表单校验 - 错误信息展示在控件下方，字段获得聚焦时清除错误态。 - 禁用控件必须说明原因和解除方式。 7. 空状态 - 必须包含插图（可选）、标题、说明、行动按钮。 8. 弹窗 - 默认居中，宽度上限 480px，底部操作区右对齐。 - 危险操作用二次确认，不能直接默认执行。 9. Toast - 默认顶部或底部居中，持续时间 3 秒。 - 不阻碍用户继续操作，不能承载唯一错误信息。 10. 无障碍 - 正文与背景对比度不低于 4.5:1。 - 可点击区域最小 44x44 px。 - 键盘 focus 样式必须明显，使用 :focus-visible 描边。 - 错误提示不能只靠颜色，必须配合文字或图标。 11. 暗黑模式 - 使用语义Token，不得通过颜色反转实现。 - 层级用背景明暗和阴影表达，避免大面积纯黑。

有了这个规则文件，Prompt可以这样写：根据ui-design-rules.mdc，为“订单退款确认弹窗”输出UI说明，包含尺寸、文案、按钮状态、错误提示、无障碍要求。生成的结果大致是：弹窗标题“确认退款给用户”，正文“退款金额¥xx，原路退回”，主按钮“确认退款”，资金操作按危险按钮处理，加载时按钮文字变成“提交中…”并禁用，失败时Toast提示“退款请求失败，请稍后重试”，焦点顺序为关闭按钮、正文、取消、确认。

这些内容看起来简单，但如果没有规则约束，AI很容易漏掉“加载状态”和“焦点顺序”，而这恰恰是前端开发最需要的。

5. 常见问题：为什么Cursor生成的文档还是不像技术文档

5.1 问题一：生成的内容全是“通用常识”，没有团队信息

经常有人问我，为什么用Cursor生成的东西换到哪个团队都一样。原因很简单：你只说了“写一份接口文档”，没有给它任何团队特有的上下文。Cursor默认会从开放的训练知识里找通用写法，而不是你们团队约定俗成的东西。

解决办法分三层。第一层，在规则文件里补充团队私有约定，比如接口前缀、错误码前缀、字段命名风格、统一响应体。第二层，把一份团队历史优秀文档脱敏后放进规则文件作为Few-shot示例，让AI照着风格写。第三层，生成之后问它“你是根据哪些规则生成的”，如果发现它根本没引用你的文件，说明上下文加载有问题，需要手动@Rules或指定文件路径。

5.2 问题二：字段、枚举、错误码全靠AI编

AI生成文档有个天然毛病：它会把缺失的信息补得特别自然，让你看不出是编的。你在需求里没写明退款原因枚举，它就可能自己造一个“地址填写错误”的枚举值出来，看起来还挺合理。这类幻觉在字段表、枚举、错误码里尤其常见。

解决这个问题，我靠两条规则兜底。第一，需求输入里尽量给出业务侧已知的枚举和边界条件，不给AI自由发挥的空间。第二，在规则文件里明确写“未确认的内容必须标注TBD，禁止编造”。这样即使AI不知道，它也不会大胆发明，而是诚实标记。

生成后如果发现枚举项跟真实业务对不上，直接告诉Cursor：这是团队公认真实枚举，请替换文档里所有自造枚举。一次修正通常能覆盖同类问题。

5.3 问题三：规则文件加载不到或不起作用

规则文件没生效，原因通常是几个。路径不对，.cursor/rules目录要放在项目根目录下；文件名匹配不到，globs没覆盖到你的目标文件；版本太旧，建议升级到新版Cursor；改完没重启，上下文还停留旧版本。

排查办法：先打开命令面板搜索 “Rules”，看当前项目里到底加载了哪些规则。如果列表里没有你的文件，说明路径或格式有问题。其次在对话中主动输入@Rules，把规则文件加进去再生成一次。如果你用了globs匹配，确认目标文档后缀是否在globs范围内，比如规则写在**/*.md可以覆盖所有Markdown，写到**/api-doc.md就只能覆盖特定文件。

5.4 问题四：免费额度用完、界面语言不想看英文

Cursor有免费额度，具体次数和逻辑会调整，用完后通常可以等额度刷新，或者考虑按需订阅。我这里不推荐使用任何来路不明的第三方工具或脚本，一是安全无法保证，二是规则文件和工程上下文本来就是你自己的资产，没必要冒这个险。

界面语言方面，如果英文看着不顺手，可以在设置里找Locale或Language选项，选择简体中文后重启。这个只影响界面，不影响规则文件读取，也不会改变生成出来的文档语言。文档语言由规则文件决定，跟界面语言没有直接关系。

6. 我在真实项目里积累的三条经验

6.1 把历史优秀文档变成Few-shot示例

刚开始我把规则文件写得非常厚，列了一堆“必须”“禁止”，但生成效果只是中等。后来我意识到，AI和新人一样，规章制度背得再好，不如给一个真实案例照猫画虎。于是我把团队一份已经评审通过、开发没有返工的接口文档脱敏后，截取关键片段放进规则文件末尾，标注为“参考示例”。

从那次之后，生成的文档在术语、表格粒度、状态机描述风格上都明显更像我们自己团队写的东西。所以规则文件不只是写“要什么”，还要放“长这样”。这个技巧也适用于UI规则文件，放一段审批通过的弹窗设计说明，效果比十条规定都明显。

6.2 文档也要做版本管理和评审

Cursor生成的文档不是一锤子买卖，需求会改，方案会调，文档也要随之更新。我把所有文档放在Git仓库里，每次生成或修改都提交一次，评审在合并请求里做。这样有争议时能翻出不同版本，看是规则问题还是提示词问题，还是需求本身就变了。

我还会在每篇文档末尾加一个元信息块，记录生成时间、使用的模型、规则版本、待人工确认项。看似多此一举，但对团队协作非常有用，至少三个月后有人看到“TBD”不会以为是谁忘了删，而是能追溯到当时的确认状态。

6.3 人始终是质量的最终责任人

最后说点实在的。Cursor帮我节省了大量做初稿的时间，但它没有替我做产品决策。哪个状态是终态、哪个用户角色能点击哪个按钮、退款失败后要不要自动重试，这些业务规则仍然需要产品经理想清楚。

我现在的工作方式是把Cursor当成一个执行力很强、背景知识丰富的实习生，它可以在十分钟内给出初稿，但要求是实现前把每个“两难”标出来，评审会上一项项过。规则文件和提示词写得越细，AI的幻觉越少，文档的工程可信度越高。这个替代不了人，但能把你从“对着空白文档发呆”的状态里彻底解放出来。