Beautiful Article 修复政策（Phase 7）全解析：以最小切片驱动的高效文章修复流程

人工智能AI 技能/插件提示工程【免费下载链接】garden-skillsConardLis open-source Skills collection, featuring web design, knowledge retrieval, image generation, and more.项目地址https://gitcode.com/GitHub_Trending/we/garden-skills点击查看免费下载本文以 skills/beautiful-article/references/repair-policy.md 为核心主体深入拆解 Beautiful Article Skill 的「最小切片修复」政策为什么不允许重写整篇、每一类问题对应的最小修复单位是什么、修复日志repair-log.md怎么写。读完本文你将掌握一套可复制的文章修复方法论——先定位问题属于哪一层再只改最小的切片让长文迭代又快又稳。Beautiful Article 是 ConardLis Skills 集合中负责「把素材编辑成单文件 HTML 网页文章」的 Skill。它的完整生产流程被编排为 Phase 0Intake到 Phase 8Delivery八个阶段其中Phase 7Repair最小切片修复决定了文章的迭代质量无论终审Phase 6或用户验收发现问题修复都必须「按最小单位进行」禁止把一次小反馈扩大成整篇重写。本文即围绕这份修复政策展开说明它的边界红线、问题分类表、日志规范与执行流程并结合仓库源码说明它与质检协议的衔接方式。一、Phase 7 在整条生产链中的位置在 Beautiful Article 的八阶段工作流中见 skills/beautiful-article/SKILL.mdPhase 7 紧跟在终审之后Phase 4 First Spread 首屏 第一节 一个代表性视觉块脚手架在此创建 Phase 5 Full Article Build 生成完整网页文章默认单 Agent超长可按 Section 隔离 Phase 6 Final Review Editorial / Visual / Technical 三视角终审写 review/final-review.md Phase 7 Repair 最小切片修复有修复才写 repair-log.md Phase 8 Delivery ★Checkpoint 3 必须停。逐项确认交付决策从源码结构看Phase 7 是一个「收敛」节点它不产生新的文章内容而是把 Phase 6 三视角终审、Section Reviewer 以及用户反馈中发现的 fail 项逐一用最小代价修复干净为最终的交付Checkpoint 3铺路。因此修复政策的核心不是「怎么修」而是**「修到什么边界为止」**——避免一次反馈触发连锁重写让文章在反复迭代中保持结构稳定。二、最小切片原则一句话定义repair-policy.md开篇第一行即给出定义按最小单位修复。有修复才写review/repair-log.md一次过 / 无修复则不写。拆开来看这一句包含两条约束修复粒度约束任何问题都只改动「能解决该问题的最小单位」而不是问题所在段落所属的整章、整篇文章。日志写入约束review/repair-log.md不是例行产物——只有真正发生修复时才写如果一次通过、没有修复则不创建该文件。这与 Skill 的硬性质检协议一脉相承review/目录下仅first-spread-review.md和final-review.md是常规产物见 skills/beautiful-article/SKILL.md 的工作区结构说明其余 review/repair 文件都按需产生避免无意义的文件污染。注意这里提到的review/repair-log.md、plan/plan.md、article/sections/等均指由 skills/beautiful-article/scripts/scaffold.sh 在 Phase 4 创建出的文章工作区内的相对路径工作区结构详见 skills/beautiful-article/references/scaffold.md而非仓库本身每个新文章项目都会生成自己的一套source/ plan/ review/ article/记忆目录。三、三条禁止红线修复的边界repair-policy.md明确列出三条「禁止」这是整份政策中最强硬的约束禁止项背后的风险用户只反馈一处问题就重写整篇把小反馈放大成大改动浪费 token、破坏已确认的成果为了修视觉而改动已确认的文章结构结构是 Checkpoint 1/2 用户确认过的契约视觉问题应只动视觉切片为了压缩信息而删除用户指定必须保留的内容信息保留比例如 longform 的 100%是用户确认过的硬承诺这三条红线共同指向同一个原则已确认的决策不得被一次局部修复悄悄推翻。这与 Skill 中「决策收集铁律 · 禁止静默替用户选择」一脉相承——修复阶段同样不允许用「顺手改一下」的方式篡改用户已经拍板的结构与内容取舍。结合 skills/beautiful-article/references/information-density.md 可以理解第三条红线的分量每种文章类型都绑定了标配信息保留比例longform100%、tutorial90%、full-report80% 等而「必须保留的信息」在plan/plan.md的 Brief 段逐条列出、由 Section Reviewer 逐一核对。若在修复时以「压缩」为名删掉这些内容等于同时违约了 Plan 承诺和用户确认。四、最小切片对照表问题 → 修复单位这是repair-policy.md的核心实操内容完整继承如下问题最小修复单位信息缺失对应 Section / Table / CodeBlock信息太密对应 Section 的段落和局部 Raw主题不对plan/plan.md的 Theme 段 局部 token / Raw图片不对对应图片和plan/plan.md的 Assets 段首屏不对Hero / Lead / SummaryRaw 跑偏单个 Raw block移动端问题对应 CSS / 组件布局构建错误具体文件和行逐行解读这张表能提炼出三类修复语义内容层信息缺失、信息太密修「对应 Section 的段落」级别只增删该节文字不动其它章节。规划层主题不对、图片不对问题源头往往在plan/plan.md因此修复单位是规划文件的对应段 受影响的局部实现token / Raw / 图片。这印证了 plan 文件作为「长期记忆」的地位——改决策要去源头改而不是只改表象。表现层首屏、Raw、移动端、构建各自收敛到单一对象——Hero/Lead/Summary、单个 Raw block、对应 CSS/组件、具体文件和行。值得强调的是「Raw 跑偏 → 单个 Raw block」这一行在 Beautiful Article 中Raw 是文章的关键表现力层可写任意 HTML/CSS/JS/React但颜色/字体/间距必须取自主题--ra-*token详见 skills/beautiful-article/references/raw-policy.md。当某块 Raw 出现「野生样式」或表达失当时修复只针对那一个 block既不牵连其它 Raw也不允许把整篇的 Raw 风格推倒重来。五、repair-log.md 的格式规范repair-policy.md给出了修复日志的固定模板## 日期 谁反馈 / 哪个 Reviewer - 问题一句话 - 定位层节奏 / 视觉 / 内容 / 构建 - 最小修复单位Section 03 / raw-blocks/02 / main.tsx 主题 ... - 改动改了什么 - 验证dev 预览 / npm run html 通过 / 控制台无错模板包含五个字段每个字段都对应修复流程的一个环节字段作用日期 谁反馈追溯问题来源用户 / 哪个 Reviewer便于复盘问题用一句话说清现象避免含糊定位层在「节奏 / 视觉 / 内容 / 构建」四层中选一个对应下文五节的四层分类最小修复单位精确到 Section 编号、Raw block 编号或具体文件名改动 验证记录「改了什么」与「怎么证明改对了」其中「验证」字段对应的命令在 skills/beautiful-article/references/html-output.md 有完整清单npm run dev启动预览Phase 4/5 边写边看、npm run build做tsc --noEmit类型检查并构建自包含单页 HTML、npm run html复用 build 并把产物复制到article/article.html最终交付物、npm run typecheck仅做类型检查。日志里写「npm run html 通过」意味着构建 类型检查全绿错误不会漏进交付物。六、修复执行流程定位 → 改切片 → 验证repair-policy.md的收尾句定义了完整执行顺序先定位是哪一层内容 / 结构 / 视觉 / 构建再改最小切片不要重做整篇。由此可以归纳出一次合规修复的三步流程定位层判断问题落在「节奏 / 视觉 / 内容 / 构建」哪一层或对照上表的八类问题归类。这一步决定后续改动的对象域。改最小切片按对照表选择最小修复单位并动手。例如「构建错误」就只改「具体文件和行」比如修 assets/scaffold-template/article/Article.tsx 或某个sections/NN-*.tsx里的具体代码行而不是重建工程。验证用npm run dev预览、npm run html确认构建通过、检查浏览器控制台无报错把验证结果写进repair-log.md的「验证」字段。从源码结构看这种「切片化」修复之所以可行是因为 Skill 有一条铁律一个 Section 一个组件文件article/sections/NN-*.tsxArticle.tsx只做 assembler 组装见 skills/beautiful-article/references/section-build.md。文件级隔离让「修 Section 03 只碰03-*.tsx」成为物理上可执行的约束同理大型 Raw 隔离在article/raw-blocks/NN-*.tsx所以「Raw 跑偏 → 单个 Raw block」能精确落点。可以说最小切片修复不是修复阶段才发明的纪律而是从 Phase 5 的文件组织规则中生长出来的必然结果。七、与质检协议的衔接谁发现问题修什么repair-policy.md处于整个质检体系的最末端它消费的所有「问题」都来自上游质检节点。结合 skills/beautiful-article/references/review-checklist.md 的质检方式表可以看清这条「发现 → 修复」链路节点质检方式产物修复落点Phase 1 Source主 Agent 内联 checklist无文件直接改source/source.mdPhase 4 First SpreadFirst Spread Reviewer SubAgentreview/first-spread-review.md首屏 / 封面 / 01-*.tsxPhase 5 每个 SectionSection Reviewer SubAgent消息返回 pass/fail对应sections/NN-*.tsxPhase 6 终审Editorial / Visual / Technical Reviewerreview/final-review.md按三视角 fail 项切片修复Phase 7——有修复才写review/repair-log.md按最小切片对照表两个细节值得注意拿到结论先修复再汇报SKILL.md 硬性质检协议第 4 条明确规定「拿到任何质检结论——先按 fail 项把产出改完再汇报」。这与repair-policy.md「有修复才写 repair-log」共同构成闭环结论不是拿来报告的而是拿来修复的。序号问题是一类典型「最小切片」问题Technical Reviewer 的清单要求章节序号全篇自洽01/02/03…连续单调、子节前缀对齐父章节。由于 Section 的index是手写字符串、组件不自动编号并行模式开发模式 B最容易出现「第 08 章下挂 5.1」这类错号。修复时只需改对应 section 文件的index字符串就是教科书式的「具体文件和行」级最小修复。八、为什么这条政策值得单独成文「按最小切片修复」看起来是一条朴素的工程常识但在 AI 生成长文的场景下它恰恰是质量与成本的平衡点质量上首屏Hero/Lead/Summary、结构、信息保留比例都是用户逐项确认过的决策Checkpoint 1/2局部修复不动这些决策文章才不会在一次反馈后「漂移」。成本上重写整篇意味着重新生成所有 Section 并重新通过全部质检而一次定位准确的切片修复只需几行改动。可审计性上repair-log.md五字段模板让每次修复都有据可查——问题从哪来、定位在哪层、动了哪个切片、验证结果如何全部落盘。如果你正在用 Beautiful Article 生产网页长文或想借鉴它的修复纪律到自己的内容流水线本文的对照表与日志模板可以直接照搬更完整的修复上下文各 Reviewer 的自检清单与 prompt 模板可以继续阅读 skills/beautiful-article/references/review-checklist.md而整个 Skill 的八阶段流程则见 skills/beautiful-article/SKILL.md。赞分享人工智能AI 技能/插件提示工程【免费下载链接】garden-skillsConardLis open-source Skills collection, featuring web design, knowledge retrieval, image generation, and more.项目地址https://gitcode.com/GitHub_Trending/we/garden-skills点击查看免费下载相关推荐OLMo 数据集构建实操3 步把原始文本变成可训练数据OLMo 数据集构建实操3 步把原始文本变成可训练数据 你想用 OLMo 训练语言模型第一道坎往往不是模型而是数据原始文本散在一堆压缩 JSON 文件里人工智能大模型预训练微调OpenChamber 从已验证 Issue 到最小修复/bug-work 命令驱动的 Bug 工作流全解析OpenChamber 从已验证 Issue 到最小修复/bug work 命令驱动的 Bug 工作流全解析 OpenChamber 是一个基于 OpenCoAI Agent人工智能代码智能体交互助手tunnelto终极指南3分钟让本地服务拥有公网访问能力tunnelto终极指南3分钟让本地服务拥有公网访问能力 你是否曾遇到过这样的困扰开发了一个本地Web应用或API服务想要分享给同事测试却因为内网限制无网络CLI后端上一篇Infinite Scroll动态导入组件React.lazy与Suspense结合下一篇UMD终极指南10分钟掌握通用模块定义模式创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考