Menu
追踪文章审稿意见，将编辑反馈结构化记录并逐条落实。触发词：审稿意见/修改文章/这里写得不好/审稿反馈/帮我追踪这个意见。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
AI配图能力层 Skill。任何需要生成信息图的任务都调用此 Skill，而不是自行调用 API。包含：模型选择、API调用、多视角草图流程、风格库引用、配图索引联动。触发词：「需要绘图」「生成配图」「画一张图」「制作信息图」「根据这段文字画图」「图片提示词」。
架构/系统差距分析 Skill。将当前系统/代码库/文档与目标框架/标准/竞品对比，生成带证据链的差距报告（兼容/冲突/缺失三类），为整改计划提供输入。触发词：「对比XXX和YYY」「这两个项目有什么异同」「找出差距」「现有系统与目标有什么不对齐」「竞品分析」「和XXX相比缺什么」。
分析文章可用的多种配图视角，为每个角度生成提示词草图供用户选择。触发词：帮我分析配图角度/生成多视角草图/配图有几种选择/给我几个配图方案。
管理他山公众号的配图风格库，提供风格模板调用和新风格沉淀。触发词：调用风格库/用XX风格/存入风格库/更新风格模板/风格库有哪些风格。
按郑总的审稿标准审阅中文文章草稿，检查AI腔、标题写法（4种错误类型）、绝对表达、结构层次污染、结语完整性，逐条给出修改方案。当用户说"审稿""帮我检查文章""review一下"时使用，也可在完成文章草稿后主动执行。
Bug修复循环协调者。测试完成后，读取技术问题追踪台，按P0→P1→P2顺序协调修复，每修复一个触发针对性回归测试，循环直至P0+P1全清，输出可上线结论。所有信息通过文档传递，不依赖对话历史。触发词：「全自动修复循环」「按Bug清单修复」「修复所有问题」「循环修复到上线」「开始bug修复循环」。
| name | article-review-tracker |
| description | 追踪文章审稿意见，将编辑反馈结构化记录并逐条落实。触发词：审稿意见/修改文章/这里写得不好/审稿反馈/帮我追踪这个意见。 |
定位：wechat-article-writer 的配套 Skill，专门处理文章写完后的编辑反馈。 与 issue-tracker 的区别：issue-tracker 追踪产品/技术问题；本 Skill 追踪文章编辑反馈。
关系类型：extends wechat-article-writer
Step 1 确认当前文章：读取对话上下文中最近的文章文件路径 → 若上下文无法确认，询问用户：「请告诉我文章文件路径或名称」
Step 2 解析用户的审稿意见（支持以下格式）： - 一句话口语化反馈（「这段AI腔太重」） - 多条列表（「1. 标题太平庸 2. 第三段冗长」） - 引用原文后评论
Step 3 结构化写入意见文件（追加式，不覆盖已有内容）： 路径：[文章同目录]/审稿意见_[文章名].md
若文件不存在 → 创建并写入表头：
`| ID | 位置/章节 | 意见描述 | 严重程度 | 状态 | 修改方案 |`
`|---|---|---|---|---|---|`
每条意见追加一行：
`| R001 | [位置] | [意见描述] | P0/P1/P2 | 🔲 待处理 | （待定） |`
ID 格式：R + 三位数序号（R001、R002…），按文件内已有最大序号递增
Step 4 逐条呈现意见摘要，为每条提出修改方案，询问用户确认： 「以下意见已记录，请确认修改方案： - R001 [P0] [位置]：[意见] → 建议：[修改方案] - R002 [P1] [位置]：[意见] → 建议：[修改方案] 是否按此方案修改？」
Step 5 用户确认后，执行文章正文修改： - 修改对应段落/标题/表达 - 更新意见文件中该条状态为 ✅ 已解决，填写实际修改方案
Step 6 所有意见处理完后，输出「审稿完成摘要」：
✅ 审稿完成 共处理 N 条意见：P0×N / P1×N / P2×N 已解决：N 条 / 已存档：N 条 / 遗留：N 条 意见文件：[文件路径]
| 状态 | 含义 |
|---|---|
| 🔲 待处理 | 已记录，尚未修改 |
| 🔄 修改中 | 正在讨论修改方案 |
| ✅ 已解决 | 已修改文章正文 |
| ⛔ 已存档 | 不修改，附存档理由 |
| 级别 | 定义 | 处理策略 |
|---|---|---|
| P0 | 影响文章核心质量：逻辑错误 / AI腔严重 / 标题有问题 / 事实错误 | 必须修改，不可存档 |
| P1 | 改了明显更好：表达生硬 / 段落冗长 / 例子不当 / 结构不清 | 建议修改，存档需说明理由 |
| P2 | 细节打磨：标点 / 措辞 / 格式 / 轻微冗余 | 可选，用户决定 |
| Skill | 关系 |
|---|---|
| wechat-article-writer | 上游：文章写完后触发本 Skill |
| article-proofreading | 平行：article-proofreading 是 AI 主动审稿；本 Skill 是用户反馈追踪 |
| issue-tracker | 区分：issue-tracker 追踪产品/技术 bug；本 Skill 追踪文章编辑反馈 |
# 审稿意见 — [文章名]
创建时间：YYYY-MM-DD
最后更新：YYYY-MM-DD
| ID | 位置/章节 | 意见描述 | 严重程度 | 状态 | 修改方案 |
|---|---|---|---|---|---|
| R001 | 标题 | 标题太平庸，缺乏吸引力 | P0 | ✅ 已解决 | 改为「XXX：YYY」强调核心洞见 |
| R002 | 第三段 | AI腔太重，「值得关注」「不可忽视」等套话密集 | P0 | ✅ 已解决 | 删除套话，改为具体描述 |
| R003 | 结语 | 结语虎头蛇尾 | P1 | 🔲 待处理 | （待定） |
根因：wechat-article-writer 无配套审稿意见管理机制，用户的编辑反馈（如「标题太平庸」「这段AI腔太重」）只能口头沟通，容易遗漏或重复确认。issue-tracker 只覆盖产品/技术类问题，不适合管理文章编辑类反馈。（信号类型 E：缺失 Skill）
经验核心：文章编辑反馈需要独立的追踪机制，与产品/技术 issue 分离管理。
验证状态：🔵 待验证