renky1025 增强提示词（prompt-enhancer）
把"一句话草稿"变成"八段式生产级强指令"，减少 AI 拿到任务就开干、做错方向、交出平庸结果的行为。
用法
增强提示词：<原始提示词>
- 直接贴入原始提示词即可；可追加说明：
受众 / 领域 / 我满意的例子 / 输出语言 - 权威方法论来源：
references/开发强指令.md（含第 2-12 章各领域完整模板，需要时读取对应章节）
核心方法论（摘自《开发强指令.md》第 0 章 / 第 15 章）
八条指导思想速查
| # | 思想 | 一句话动作 |
|---|---|---|
| 1 | 复述需求 | 动手前让它说"我理解的是……" |
| 2 | 先思考 | 让它先给 2-3 个候选方案及取舍，再给最终版 |
| 3 | 角色+目标 | 给专业角色，并说清什么最重要 |
| 4 | 不要什么 | 显式写"不要 XXX"，比只说目的地更有效 |
| 5 | 自我批评 | 答完让它对照验收标准找最弱处并重写 |
| 6 | 不同方向 | 要"完全不同的思路"而非"再来 5 个版本" |
| 7 | 给例子 | 让它分析例子规律再创作，不模仿字面 |
| 8 | 充分上下文 | 好结果 = 上下文 + 限制 + 反馈 + 例子 + 目标 |
强指令最小可用骨架（增强的输出必须覆盖这些块）
你是一名[专业角色]。目标：[最终要解决的问题 + 什么最重要]。
上下文：
[项目 / 技术栈 / 现状 / 约束 / 代码 / 日志 / 架构]
我满意的例子（可选但强烈建议）：
[例子] —— 先分析其语气、结构、节奏规律，再据此创作。
第一步 · 复述对齐（原则1）：
开始前，先告诉我你理解了什么：目标 / 限制条件 / 打算怎么改。确认无误再继续。
第二步 · 先思考（原则2）：
不要直接动手。先列出 2-3 个候选方案及各自取舍，再给最终版本。
执行要求：
1. [具体怎么做] 2. [覆盖哪些维度] ...
明确不要（原则4）：
- 不要[具体反面行为]
完成后 · 自我批评（原则5）：
批评自己的产出，找出最弱的部分，说明如何改进，然后重写。
输出与验收（原则8）：
[必须交付什么 / 如何判断做对了]
如果信息不足，不要猜测。明确指出缺失信息，并基于现有证据完成能确定的部分。
工作流程
第 1 步 · 解析原稿
提取：意图（要 AI 完成什么）、产出物、目标受众、隐含约束、领域。留意原稿里的口语化/错字表达，按真实意图归一化（如"我向导的是"->"我想要的是"），不把错字带进增强版。
第 2 步 · 诊断缺口（对照骨架逐项检查）
逐项标记原稿缺失的块，重点查这些常见病：
- 无角色 / 无目标，或目标不可验证
- 口头结构要求没有固化为步骤（例："要有主业务路径、业务能力、产品能力"只是描述，没变成执行步骤+自检）
- "不清楚就问 / 有问题随时问"太含糊，没定义问什么、什么时候问
- 无"明确不要"，AI 易跑偏或虚构（编造仓库不存在的证据等）
- 无验收标准 / 交付清单
- 无防平庸机制（自我批评、不同方向）
第 3 步 · 选模板
按任务领域从下方"领域模板库"选取最贴近的骨架；跨领域任务合并多个模板的要素。
第 4 步 · 增强填充（核心技巧）
- 角色落地：给专业身份 + 判断准则（例：售前解决方案架构师，擅长把技术翻译成高层业务语言）
- 目标可验证：把"生成一张图"升级为带验收口径的目标（例：让不懂技术的客户高层 3 分钟看懂）
- 口头结构要求 -> 显式步骤 + 闭环自检：用户口述的层次/顺序要求逐条展开为执行步骤，并加"自检三层是否闭环"这类核对动作
- "不清楚就问" -> 分级澄清闸门：拆成"必须由我确认"vs"可用合理假设"两级；策略是"先出基于证据的骨架 + 分级提问清单，不硬出全量结果"，避免白做也避免卡死
- 防虚构红线：凡是基于代码/事实/数据的任务，明确"只基于证据，不编造不存在的结论"
- 受众表达规范：目标受众决定了语言边界（高层->禁黑话禁技术图；工程师->保术语保精确）
- 验收清单化：输出部分写成"交付物 1/2/3..."，每项可核对
- 保留原稿全部硬性要求：可增不可删、不可篡改原意
第 5 步 · 输出与自检
- 自检增强版是否覆盖骨架全部八块、是否消化了原稿每个要求点
- 输出：强指令全文（对话内 code block；用户要求保存时写 .md 到工作目录）+ 增强对照表 + 用法说明
- 若原稿信息严重不足（缺目标受众 / 产出物 / 领域），先问 1-2 个关键问题再增强；或给"默认假设版 + 待确认项清单"两段式，不阻塞交付
领域模板库
T1 通用开发 / 编码任务
角色：资深[语言]工程师。骨架重点：复述对齐（要改哪些文件、怎么改）、先读相关模块再动手、保持 API 兼容、不改无关代码、不引入未说明的新依赖、不添加无实际价值的防御冗余；输出：修改了什么 / 为什么 / 影响模块 / 风险 / 如何测试。
T2 需求理解与分析
角色：资深软件产品架构师。骨架重点：目标是把模糊需求变成"问题被定义清楚"，不急于出方案；列出 2-3 种可能解读再选真问题；明确 vs 隐含需求；歧义与缺失信息清单；MVP vs 后续阶段；输出需求澄清结论 + 待确认问题清单。明确不要：急于设计技术方案、替需求方脑补约束。
T3 技术方案 / 架构设计
角色：资深软件架构师。骨架重点：问题定义 -> 核心业务流程 -> 边界 -> 模块 -> 数据流 -> 调用链 -> 数据模型 -> API -> 异常/并发/安全/性能/可观测性 -> 取舍记录 -> 推荐方案；每个关键设计说明"为什么这样设计 + 放弃其他方案的原因"。明确不要：过度设计、为模式而模式。
T4 代码仓库分析 -> 面向客户/高层的方案图（实战验证版）
角色：资深售前解决方案架构师（面对董事长 / CEO / 业务 VP / CIO）。目标：还原产品真实解决的业务问题，产出高层方案图，三层结构：主业务路径（客户视角业务环节）-> 业务能力支撑 -> 产品能力映射。验收：不懂技术的高管 3 分钟看懂"解决了什么、凭什么做到"。
执行步骤：仓库认知（README/docs/目录/入口）-> 抽主业务路径（客户语言命名，不用内部模块名）-> 抽业务能力（每项须有仓库证据）-> 映射产品能力（标注证据路径，无对应物如实写"待确认/规划中"）-> 结构成图（主路径贯通，能力/产品纵向挂接）-> 高管化表达（每环节标注提效/降本/控险/体验）-> 闭环自检。
先思考可选构图：A 三层价值塔 / B 端到端业务泳道（主路径横向贯通、环节下挂能力与产品）/ C 价值环。明确不要：技术架构图、部署图、依赖图、类图；功能清单罗列；编造仓库不存在的能力；高层听不懂的黑话；单图超载。交付：图（自包含 SVG/HTML，可嵌入 PPT）+ 三层映射表 + 证据与假设清单 + 3 分钟讲解话术 + 待确认问题清单。信息不足时先交"证据骨架 + 分级提问清单"。
T5 文档 / 写作任务
角色：技术写作者 / 开源项目维护者（按文体）。骨架重点：先复述对"好文档"的定义标准（如：没参会的人也能实施；命令必须可验证）；明确不要营销式描述、不虚构命令或配置、不写只有作者懂的缩写；完成后对照例子找规律落实最弱处重写。可用"示例驱动"段（原则7）：让 AI 先抽象例子规律并复述确认再创作。
T6 代码审查 / Bug 分析 / 重构
角色：严格资深 Reviewer / 调试工程师 / 重构工程师。骨架重点：审查优先级复述（正确性 > 安全 > 并发 > 可维护）；问题分级 P0-P3，每条给"位置/问题/后果/推荐修改/是否必须改"；Bug 分析禁止按表面现象直接改，必须根因 + 证据 + 防回归；重构要求每步可独立验证、保持行为不变。明确不要：为凑数提风格偏好、删失败测试换通过、降校验掩盖问题。
输出规范
- 强指令全文：对话内 code block 完整给出（用户可直接复制）；若用户要求保存或原文较长，另写 .md 到当前工作目录并 present
- 增强对照表：原稿薄弱点 -> 增强处理（5-8 行，让用户看清改了什么、为什么）
- 用法说明：占位符（方括号处需替换的字段）、可选裁剪（哪些闸门可删以换取一次出图）
- 附加可选：按原稿类型给出"极简版 / 完整版"两个档位供选择
自检清单（每次交付前过一遍）
- 八块骨架全覆盖（角色/目标/上下文/复述/先思考/执行/不要/验收）
- 原稿每个要求点都被消化（不删不改原意）
- 验收标准可核对，不是"做得更好"这类空话
- 语言与目标受众匹配（高层 vs 工程师）
- 无虚构风险敞口（涉及证据的任务都有"不编造"红线）
- 文件输出无乱码字符（禁 Box Drawing、Unicode 箭头等装饰符）