企业官网建设流程全解析

持续总结实践经验

1. 用 skill-creator 生成初版

不要从空白页空想结构。用 Cursor 的skill-creator（create-skill）先出一版：目录、SKILL.mdfrontmatter、description、基本章节都按规范搭好。

初版的目标是「能跑、能触发」，不是「一次写完美」。人只补领域约束和本仓库约定，骨架交给工具，省掉格式纠结。

2. 固定逻辑脚本化，动态逻辑交给 LLM

Skill 里两类事要分开：

能算死、一算错就全盘歪的，写成脚本，并在 Skill 里写清：以脚本输出为准，禁止重算臆造。需要智能的部分留给模型。这样过程随机性会明显下降，失败也可定位到「脚本」还是「判断」。

3. LLM 必做的确定性事项，写成自然语言硬门禁

有些事没法（或不值得）脚本化，但结果必须确定——例如「未读 plan 不得落库」「清场必须进 finally」「error 清零前不得宣称完成」。这类约定交给 LLM 执行时，不要写成「建议」「尽量」「最好」，要用自然语言写成硬门禁：可判定、可违反即停、无商量余地。

软建议会被跳过；硬门禁才会改变行为。脚本管算得死的，硬门禁管「必须靠模型遵守、但结果不能飘」的那一层。

4. 生成式 Skill 必须带评测

凡是「生成产物」的 Skill（用例、代码、文档草稿等），不能停在「生成完了」。要加一层多方位评测：结构是否合规、约定是否满足、关键路径是否可跑通，等等。

评测最好可脚本化、可出下一步修复建议；未过门禁就不许宣称完成。生成 → 评测 → 按意见修 → 再评，比单纯加长SKILL.md更能稳住质量。

5. 多轮迭代后，主动清理冗余

Skill 会随踩坑变长：多一条禁令、多一段解释、多一个特例。迭代几轮后要专门做一次「减肥」：

• 删已被脚本/评测兜住的重复说明
• 删从未改变行为的软建议和背景长文
• 细节外置到旁路文件，主文件只留主路径与硬门禁

短而硬比长而全更不容易把上下文撑满，也更容易被真正执行。

6. 长任务拆成主子智能体

单次对话塞完整条长流水线，上下文会膨胀、中后段开始丢约束。做法是：把重复、可并行、边界清晰的工作拆成子任务，由主智能体编排、子智能体执行单块，再汇总结果。

主智能体只保留目标、进度与接口约定；子智能体各自带着小上下文干活。长任务不再「一条对话扛到底」，Skill 也更像编排手册，而不是巨型操作手册。

7. 用 LLM 评估 Skill 的优化空间

Skill 写完、跑过几轮之后，把失败案例、多余步骤、反复口头纠正过的点丢给 LLM，让它专门评估：哪里该脚本化、哪里该升硬门禁、哪里是冗余、哪里该拆子任务。人审结论，再改一版。

这和「评测生成产物」不同：那边验输出质量，这边审 Skill 本身是否还在帮倒忙。定期用 LLM 做一次「Skill 体检」，比凭感觉加条文更对症。

8. Skill编写纪律

原则大于规则，要记得告诉why。把AI当做聪明人，这样面对未规划场景时也能自主泛化处理。防止跑偏就需要定硬门禁。