Menu
追踪文章审稿意见，将编辑反馈结构化记录并逐条落实。触发词：审稿意见/修改文章/这里写得不好/审稿反馈/帮我追踪这个意见。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| 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 分离管理。
验证状态：🔵 待验证
AI配图能力层 Skill。任何需要生成信息图的任务都调用此 Skill，而不是自行调用 API。包含：模型选择、API调用、多视角草图流程、风格库引用、配图索引联动。触发词：「需要绘图」「生成配图」「画一张图」「制作信息图」「根据这段文字画图」「图片提示词」。
架构/系统差距分析 Skill。将当前系统/代码库/文档与目标框架/标准/竞品对比，生成带证据链的差距报告（兼容/冲突/缺失三类），为整改计划提供输入。触发词：「对比XXX和YYY」「这两个项目有什么异同」「找出差距」「现有系统与目标有什么不对齐」「竞品分析」「和XXX相比缺什么」。
分析文章可用的多种配图视角，为每个角度生成提示词草图供用户选择。触发词：帮我分析配图角度/生成多视角草图/配图有几种选择/给我几个配图方案。
管理他山公众号的配图风格库，提供风格模板调用和新风格沉淀。触发词：调用风格库/用XX风格/存入风格库/更新风格模板/风格库有哪些风格。
按郑总的审稿标准审阅中文文章草稿，检查AI腔、标题写法（4种错误类型）、绝对表达、结构层次污染、结语完整性，逐条给出修改方案。当用户说"审稿""帮我检查文章""review一下"时使用，也可在完成文章草稿后主动执行。
Bug修复循环协调者。测试完成后，读取技术问题追踪台，按P0→P1→P2顺序协调修复，每修复一个触发针对性回归测试，循环直至P0+P1全清，输出可上线结论。所有信息通过文档传递，不依赖对话历史。触发词：「全自动修复循环」「按Bug清单修复」「修复所有问题」「循环修复到上线」「开始bug修复循环」。