企业官网建设流程全解析

生产级 SKILL.md 的 7 条铁律：从 Cloudflare 文档 Linter 到 replica-skill 的共性

【免费下载链接】replica-skillEleven free Claude skills that clone any app: reverse-engineer it, rebuild it, test it for bugs, then fix what its users hate. Free, MIT.项目地址: https://gitcode.com/gh_mirrors/re/replica-skill

2026 年初，一篇深度解析 Cloudflare Docs 样式审查 SKILL 的文章在技术社区流传开来：一个以纯提示词 + 规则引擎驱动的 MDX 文档自动 Linter，通过 manifest 按需加载规则、只审查 diff 中的新增行、以结构化 JSON 输出结果，并用自动化 eval 验证规则有效性——把"低误报"和"可复现"做成了硬性工程指标。几乎同一时间，另一个开源项目 replica-skill 用十一份 SKILL.md 拼出了一条完整的"克隆任意应用"流水线：逆向、架构、设计、构建、测试、对比、品牌、上线，每一步都有配套的标准库 Python 工具做校验。

一个在给文档挑刺，一个在克隆应用，表面上毫无交集。但把两份 SKILL.md 放在一起逐条对照，会发现它们对"生产级技能包"的定义惊人一致。本文从 replica-skill 的源码出发，结合 Cloudflare Linter 的设计思路，提炼出七条可以被审查、被测试、被门禁拦截的铁律——它们决定了技能包是从"提示词模板"升级为"可交付的工程资产"的那条分界线。

一、两条线的交汇点：技能包正在变成"带契约的程序"

先说清楚 Cloudflare 那个 Linter 为什么值得作为参照系。它的核心不是"提示词写得多漂亮"，而是一整套工程约束：机械式规则匹配而非让模型自由发挥；规则按 manifest 条件加载，杜绝无关规则干扰；只审新增行，让同一份规则在任意提交上产生可预期的输出；两级严重度 + 稳定 ID，让结果可以被引用、被回归测试。

replica-skill 则把同样的思想搬进了另一类场景。它的十一份 SKILL.md 每个都是"带契约的程序"：输入是固定的（replica/features.csv、replica/reviews.csv、replica/design/tokens.json），输出是固定的（replica/parity.md、replica/feedback.md、replica/deploy.md），中间穿插六个不依赖任何第三方库的 Python 工具。README 里写得很直白：

Six of them, all standard-library Python. None touch the network.

这两条线共同说明一件事：生产级 SKILL.md 的重心不在提示词，而在它周围那圈可执行、可校验、可被 CI 拦截的工程外壳。下面的七条铁律，就是这圈外壳的组成。

二、铁律一：可复现——零依赖、固定契约、确定性输出

一个技能如果每次运行结果都取决于模型当天的状态，就无法被验收。生产级技能的第一步，是把"灵感"从关键路径上挪走。

Cloudflare Linter 的做法是机械式规则匹配 + 结构化 JSON 输出协议：规则是确定的，输出是确定性的，唯一变量被压缩到最小。replica-skill 走得同样彻底：

• 零安装依赖。六个工具全部只用 Python 标准库，运行时要求只有"Python 3.8 or newer"，没有pip install这一步，排除了环境漂移。
• 输入即契约。parity.py读取的特征矩阵有严格列约定（feature、area、priority、original、clone、notes），缺失必需列会直接报错退出；reviews.py要求每行必须有url和text，缺一即丢弃并计数。
• 可重放。reviews.py提供--today参数固定"今天"的日期，配合--months决定旧评论的衰减权重，让同一条评论数据在任何一天跑出同一份排名。

imgdiff.py甚至把 PNG 解码都自己做完了（见 replica-diff/imgdiff.py 的read_png），从 IHDR 解析到滤镜逆变换全部手写，就为了"没有任何库版本不一致的可能"。可复现不是洁癖，它是后续一切验收动作的地基。

三、铁律二：低误报——宁可漏报，不可错报

一个反复在用户面前报错、而错误与问题无关的 Linter，很快会被关掉；一个总是给错误建议的技能，会被 Agent 悄悄忽略。低误报不是体验优化，是存活条件。

Cloudflare 那边用两个机制压误报：只审 diff 新增行（已发布内容不再重复报），以及两级严重度让噪声和真问题分层。replica-skill 的对应物更具体：

• 对比工具知道"什么不该算差异"。replica-diff/imgdiff.py 的默认 layout 模式把两张截图转成边缘图，按网格比较结构分布，刻意忽略颜色——因为replica-brand本来就要换掉全部颜色，颜色差异是预期行为而非缺陷。若换用 pixel 模式精确比对，文档明确禁止拿它去追原版像素（"not to chase the original's pixels"）。
• 分析工具只呈现有把握的信号。replica-entrepreneur/reviews.py 会把少于 3 条评论或仅单一来源的主题标记为thin；样本少于 30 条时直接提示"只支持一个方向，不支持排名"。三条愤怒的 Reddit 评论不会被包装成一个趋势。
• 测试报告区分"已复现"与"可能"。replica-test/SKILL.md 规定只报告实际复现的缺陷，"Might be an issue" 只能进独立的待查清单。

低误报的本质是给每个判断设定可辩护的证据门槛。报错越少，每一次报错的分量越重。

四、铁律三：可验收——退出码即门禁

生产级技能必须能被机器验收，而最廉价、最通用的机器验收通道就是进程退出码。

Cloudflare Linter 用自动化 eval 评测规则有效性，把"规则好不好"变成可量化指标。replica-skill 则把退出码用成了贯穿全流程的门禁开关：

• replica-design/contrast.py 按 WCAG 2.2 计算全部文本/背景对比对，"Exit code 1 when any pair fails AA, so it can gate a build"；
• replica-brand/sweep.py 在代码里搜索原应用的名称、域名、品牌色，"exits 1 if it finds anything, so it can block a deploy"；
• replica-launch/listing.py 校验应用商店字数上限、排名/价格宣称、原应用名称残留，有 error 即退出 1；
• replica-diff/parity.py 支持--fail-under，得分不达标就失败。

这些工具被 replica-deploy/preflight.md 编排成一张硬性检查表：e2e 全绿、无未关闭的 S1/S2 缺陷、must-have 全部完成、sweep 干净、listing 通过、生产构建通过——"Any failure stops the deploy"。而工具的可靠性本身又被 tests/ 目录下的 57 个单元测试兜底（python3 -m unittest discover -s tests -v），连模板文件（tokens.json、features.csv、listing.example.json）都有"必须能被解析且无问题"的测试。

到这里，技能包的验收形成闭环：工具门禁检查产物，测试门禁检查工具。

五、铁律四：安全边界——能力最小化与人机分工

社区里"AI 智能体被投毒"的新闻屡见不鲜，技能包的安全边界因此从加分项变成了硬约束。Cloudflare 侧体现为 manifest 驱动的条件加载——Agent 只获得当前任务需要的规则子集，能力面被显式收窄。腾讯云运维 Agent 复盘文章里也专门提到"安全边界控制（description 与 allowed-tools）"。

replica-skill 把安全边界写进了每一份 SKILL.md 的规则区，而且边界画得极其具体：

• 数据来源边界。replica-recon/SKILL.md：只读公开页面和用户自己的账号，"Never log into an account that is not the user's, never ask for a password, never get past a paywall by any trick"；不许爬虫、不许批量下载、不许翻源码或抓私有 API。
• 凭据边界。replica-backend/SKILL.md 和 replica-deploy/SKILL.md：Claude 永不注册账号、永不输入密码/银行卡/线上密钥；Stripe、Supabase、域名由用户创建和购买，Agent 只负责写好.env.example、DNS 记录和环境变量名，敏感操作全部归还给用户。
• 测试边界。replica-test/SKILL.md 开宗明义："Test your clone, not the original"，绝不对原应用服务器做压测、模糊测试或脚本轰炸。

这些边界不是修辞，而是和工具逻辑咬合在一起的：sweep.py跳过了replica/规划目录，因为那里面"本来就该出现原应用的名字"；replica-recon/features.csv 里第三方应用市场被标成skip，理由是"their partner network is not part of the product you can rebuild"——边界用数据行表达，而不是用语气表达。

六、铁律五：零虚构——每一条结论都必须有证据链

幻觉是生产级技能最致命的敌人。Cloudflare Linter 用"结构化 JSON 输出 + 稳定 ID"让每条审查结果可被追溯到具体规则；replica-skill 把同样的追溯性推到了极致，尤其是在处理用户评论的 replica-entrepreneur/reviews.py：

This tool only reorganises what you give it. It does not write reviews, it does not paraphrase them, and every quote it prints is a substring of a row you supplied, with that row's link.

工具层面：无链接的评论行直接丢弃并计数（"Nothing is counted without its source"），重复文本被去重，引文只能是原始文本的子串。技能层面：replica-entrepreneur/SKILL.md 规定 "Never fabricate"，引用必须逐字且带 URL，刷假评论在美区违反 FTC 2024 新规，评论者的原话只能当研究材料、不能当自家落地页的 testimonial。呼应地，replica-launch/SKILL.md 也禁止虚构任何"proof"：没有真实测试用户的空证明区，好过编造的 "trusted by"。

证据链思维还反向用在品牌安全上：listing.py会在商店元数据里查原应用名称，sweep.py连OriginalAppEmbed这类嵌在标识符里的名字都不放过。不虚构自己的数据，也不残留他人的品牌——这是同一枚硬币的两面。

七、铁律六：显式编排——稳定 ID 与顺序依赖

一个生产级技能包很少是孤立的单技能，而是一组相互消费产物的流水线。编排得当与否，决定了整条链路的可维护性。

Cloudflare 架构里对应的是 Agent 实例化、可信调度与结果合并——多个实例各审一段，再按稳定 ID 汇总。replica-skill 的编排哲学更朴素，但同样严格：

• 稳定 ID 贯穿全局。replica-recon/SKILL.md 规定屏幕编号 S01、S02…"IDs are stable…Every other file refers to them"；测试用例编号 F01-H1、F01-E3、F01-N2 同样被 replica-test/SKILL.md 强制。
• 顺序依赖是显式契约。README 画出完整链路recon -> architect -> design -> build -> backend -> test -> diff -> entrepreneur -> brand -> launch -> deploy，每个技能"reads what the last one wrote"；replica-architect遇到没有 recon map 的情况会直接停下，要求先跑/replica-recon（"Planning a clone from memory of what an app does is how you miss half of it"）。
• 同一份数据被反复消费。features.csv从 recon 生成，被 build 逐行勾选、被 diff 计分、被 deploy 当作 must-have 门禁——一个文件串联起四个技能的状态。

这提示了一个容易被忽略的点：技能的编排价值不靠长提示词叙述流程，而靠稳定的数据契约把上下游焊死。ID 稳定，diff 才有意义；文件固定，消费方才敢依赖。

八、铁律七：诚实量化——给数字，不给 vibe

最后一条铁律，是把"效果如何"从形容词变成数字。

Cloudflare 侧的表现是 eval 评测与低误报率的量化声明。replica-skill 则把"诚实"写进了计分逻辑和措辞纪律：

• replica-diff/parity.py 用加权计分：must=3、should=2、could=1，partial 计一半，skip行和"你额外加的功能"行完全不参与计分——"the number only ever measures parity"。must-have 未完成时输出明确裁决："Not shippable yet"。
• replica-diff/SKILL.md 的纪律是："Give honest numbers. A clone at 62% is at 62%."，并把结论收敛成三档：不可发版（must 缺失或 S1 未关）、可发版（must 全齐、功能分 80+）、以及作为目标的"better than the original"——一个纯拷贝没有存在的理由。
• recon 阶段就要求诚实估规模（S/M/L/XL），README 明言 "No guarantee of a 'perfect' clone"，复杂应用被提前打回重定范围。

配合测试环节的严重度模型（S1 数据丢失/支付错误/核心流程阻塞，S2 功能坏且无绕过，S3 有绕过或明显错误，S4 纯外观），整个链路从规模预估到最终交付，每一步都有数字可以复盘。量化未必精确，但至少可被挑战——这比一句"效果很好"值钱得多。

九、把铁律套回你自己的技能包：七问自检清单

与其记住七条抽象原则，不如把它们变成一份可执行的自检清单。以下每个问题都能在 replica-skill 的源码里找到答案，你也可以用同样的问题审查自己的技能包：

1. 可复现：你的技能是否零依赖、输入输出是否有固定 schema、同样的输入能否跑出同样的结果？（对照：replica-diff/parity.py 的列校验、reviews.py的--today）
2. 低误报：你的检查工具是否知道"哪些差异不该报"？可疑信号是否被降级为 thin / to-check 而非直接报错？（对照：replica-diff/imgdiff.py 的 layout 模式）
3. 可验收：你的检查器是否用退出码表达成败？是否有一张 preflight 清单把所有门禁串起来？检查器本身有没有测试？（对照：replica-deploy/preflight.md、tests/）
4. 安全边界：你的技能是否声明了数据来源边界、凭据边界、测试边界，并把边界落到工具逻辑里？（对照：replica-backend/SKILL.md 的 rules）
5. 零虚构：你的分析结论是否每条都可追溯到带 URL 的原始证据？工具是否会丢弃无证据的行？（对照：replica-entrepreneur/reviews.py 的 dropped 计数）
6. 显式编排：你的多技能流水线是否用稳定 ID 和固定文件做契约，而不是靠叙述？（对照：replica-recon/features.csv 被四个技能消费）
7. 诚实量化：你的结论是数字还是形容词？是否声明了样本量、权重规则和不计分项？（对照：replica-diff/parity.py 的 must/should/could 加权）

一个技能包从"能跑通演示"到"敢在生产环境放行"，差的就是这七条铁律。Cloudflare 的 Linter 和 replica-skill 的克隆流水线用了完全不同的领域语言，却在同一份答案上相遇：把判断权交给规则与证据，把执行权留给模型，把验收权交还给机器。你的下一个技能包，也可以从给第一条规则加一个退出码开始。

【免费下载链接】replica-skillEleven free Claude skills that clone any app: reverse-engineer it, rebuild it, test it for bugs, then fix what its users hate. Free, MIT.项目地址: https://gitcode.com/gh_mirrors/re/replica-skill