企业官网建设流程全解析

导读

claude-token-efficient项目提供一套精简的 Claude 会话规则，用于约束输出、压低 token 消耗。本文围绕 profiles/RULES-IN-PROMPT.md 展开，完整讲解"把规则粘贴进提示词（Rules in prompt）"与"使用 CLAUDE.md 文件"两种注入方式的区别、适用场景与真实成本数据，并结合仓库基准测试脚本与 v8 配置，给出可复现的验证路径。读完本文，你可以为一次性任务和长期项目分别选对规则注入方式，并知道如何用仓库自带工具量化两种方式的 token 与费用差异。

一、规则正文：可直接粘贴进会话的 8 条规则

profiles/RULES-IN-PROMPT.md的用途非常直接：不依赖项目配置，把一段规则粘贴到任意新会话开头即可生效。原文给出的完整规则块如下，可直接复制使用：

Rules for this session: - Think before acting. Read existing files before writing code. - Be concise in output but thorough in reasoning. - Prefer editing over rewriting whole files. - Do not re-read files already read unless file may have changed. - Test your code before declaring done. - No sycophantic openers or closing fluff. - Keep solutions simple and direct. - User instructions always override this file.

这 8 条规则与本仓库根目录 CLAUDE.md 的 Approach 段高度同源：先读文件再写代码、输出简洁、倾向小范围编辑、避免重复读同一文件、写完必须测试、禁止奉承式开头与结尾废话、方案保持简单直接、用户指令永远优先。仓库还提供了更精简的通用版本 RULES.md（短句化、去掉填充词、优先给结果、压缩英语表达），以及面向不同场景的 profile，例如 profiles/CLAUDE.coding.md（开发/代码审查/调试）与 profiles/CLAUDE.agents.md（自动化流水线）。

使用提示：粘贴规则后，本会话即受约束；一旦你显式要求详细解释，规则中的"用户指令优先"条目会立即让位。

二、两种注入方式：机制、成本与适用场景

2.1 CLAUDE.md 文件（推荐方案）

• 在项目根目录放置CLAUDE.md，每条消息自动加载；
• 内容可被高效缓存，重复读取不重复计费；
• 无需任何复制粘贴操作；
• 根据仓库基准数据，每基准成本比提示词方案约低30%；
• 适合常规开发、流水线等重复性工作。

2.2 提示词内粘贴规则（备选方案）

• 无需项目设置，任何会话都能立即使用；
• 规则生效范围清晰，一眼就能看出本次会话应用了哪些规则；
• 适合一次性任务；
• 根据仓库基准数据，成本比 CLAUDE.md 方案约高41%。

2.3 为什么会有成本差

README 中的"Honest trade-off"章节点明了本质：CLAUDE.md 文件本身每轮都会消耗输入 token，省下的钱来自输出 token 的缩减。因此净收益只有输出量大到足以抵消固定输入开销时才为正。提示词粘贴方案同样要承担这部分输入开销，同时缺少缓存收益，所以在同一组基准任务上成本更高。

两种方式的完整定位见下表：

三、基准数据：3 个挑战下的成本实测

文档中的核心证据来自 3 个编码挑战（CSV 报告器、SQLite 窗口函数、WebSocket 计数器），两种方式在同一测试平台上跑出的成本对比如下：

两个结论：

1. 两者都能通过全部 3 项测试，功能性上没有差距；
2. 成本差异主要在 WebSocket 挑战上：$0.585 对 $0.285。README 解释这与 v8 配置的显式模式规则有关——提前写死 WebSocket 的实现模式（见下文 4.2 节），避免了昂贵的调试循环。

该组数据同时记录在 README.md 的 "Two Ways to Apply Rules" 小节，作为 v8 配置（$0.935）与提示词粘贴方案（$1.318，贵 41%）的对照基准。

四、v8 配置为何更省：最小化规则集的代价与收益

4.1 极简配置结构

v8 是仓库中面向成本敏感流水线的版本化配置，位于 profiles/M-drona23-v8/：

• CLAUDE.md 仅一行："A coding project. Read .claude/rules/ before starting."
• rules/workflow.md 才是真正的规则主体，核心约束是20 次工具调用预算：

You have a strict budget of 20 tool calls. Plan carefully. 1. Read ALL files including test file first. The test defines what passes. 2. Write the COMPLETE solution in a single file write. Not incrementally. 3. Run tests once. If pass: stop immediately. If fail: read error, fix once, retest. 4. Never iterate more than once on the same failure. Rethink if stuck. 5. Never refactor, improve, or polish passing code. 6. For WebSocket: use a Set to track clients manually. Send to sender first, then broadcast to others via setTimeout(0). Never use pub/sub channels.

注意它仍然遵循 RULES-IN-PROMPT.md 的注入哲学：CLAUDE.md 只做一行"引导指针"，具体规则放在子目录规则文件中，避免把长内容塞进主文件造成每轮输入开销。README 中"CLAUDE.md files compose"一节说明了这一设计依据：全局（~/.claude/CLAUDE.md）、项目级、子目录级多个 CLAUDE.md 会被同时读取，通用偏好放全局、项目约束放项目级、任务级规则放子目录，任何单文件都不会膨胀。

4.2 模式规则的价值

v8 与旧版 C-structured 配置在同一天、同一模型、同一测试平台上头对头对比（数据见 README.md）：

合计节省约 17.4%，其中最大单项收益来自 WebSocket：workflow.md 第 6 条预置了"用 Set 手动跟踪客户端、先发给发送者再 setTimeout(0) 广播"的固定实现模式，杜绝了反复试错的调试循环。这说明 RULES-IN-PROMPT.md 中"规则可以只针对本会话生效"的特点，与 v8 的"把高成本任务的正确做法直接写死"思路是一脉相承的。

五、如何验证：用仓库基准脚本复现成本数据

profiles/RULES-IN-PROMPT.md给出的对比数据来自外部测试平台（README 的 Issue #1 外部基准，6 种配置、3 个编码挑战）。如果你想在本地自行验证规则文件的效果，仓库提供了两套自动化工具，可以复现与文档口径一致的 token 与成本指标。

5.1 token 基准：benchmark/run.py

该脚本驱动本地claudeCLI 的 print 模式（-p），复用已登录的 OAuth 会话，无需 API key。核心机制：

• 每个 prompt 在全新的/tmp临时目录运行：基线条件为空目录，处理条件把目标 CLAUDE.md 复制进去；
• 通过--setting-sources project屏蔽全局设置与 hooks，确保只有目录内的 CLAUDE.md 是变量；
• 记录真实output_tokens、词数、费用（total_cost_usd），并写入 JSONL 原始日志；
• 内置限流/过载重试与指数退避。

基础用法：

python3 benchmark/run.py # 基线 vs 仓库 CLAUDE.md python3 benchmark/run.py -n 5 --model sonnet # 每个条件跑 5 次，sonnet 模型 python3 benchmark/run.py \ --variant lean=profiles/M-drona23-v8/CLAUDE.md \ --variant coding=profiles/CLAUDE.coding.md # A/B/C 多配置对比

常用参数：-n/--runs每个单元的运行次数（默认 3）、--model（默认 haiku，可选 sonnet/opus）、--workers并发调用数（注释明确提示 3 为甜点位，4+ 会触发限流，opus 建议 2）。运行后自动生成 benchmark/report-{model}.md 风格的逐 prompt token 表与费用汇总。

仓库已附带三份模型结果，见 benchmark/SUMMARY.md：当前精简版 CLAUDE.md 下输出 token 减少约 4%（haiku）、18%（sonnet）、5%（opus）；排除格式测试 T4 后约为 2%（haiku）、11%（sonnet）、7%（opus）。而激进压缩版 profiles/CLAUDE.compressed.md 效果更强：opus 上可达 -62%。同一份文档明确指出：README 宣传的 63% 在当前精简 CLAUDE.md上无法复现，只有用压缩 profile 在 opus 上才能接近该量级——这正是"规则应匹配真实失败模式"的实证。

5.2 语义评估：benchmark/eval.py

token 数字不能说明行为是否真的改变，语义评估回答这个问题：

• 对已捕获的原始响应（benchmark/raw-*.jsonl）做两层分析：机械检测器用确定性正则检查 preamble、sycophancy、closing fluff、"as an AI"、em-dash、smart quotes 等标记；LLM 裁判（haiku，无 CLAUDE.md）只按内容评分准确度、完整度与关键点命中；
• 5 个测试各自绑定一个语义关键点，例如 T2-review 必须指出i<=arr.length是 off-by-one 缺陷，T5-halluc 必须纠正"Python 由 James Gosling 发明"并给出正确归属（Guido van Rossum）。

python3 benchmark/eval.py # 处理全部 raw-*.jsonl python3 benchmark/eval.py --raw benchmark/raw-opus.jsonl python3 benchmark/eval.py --no-judge # 只跑机械标记，不消耗模型调用

评估结论（benchmark/SEMANTIC.md）揭示了一个重要事实：当前模型基线上 preamble、sycophancy、"as an AI"、smart quotes 大多已经为 0%，针对这些行为写规则只会增加输入成本而不会改变输出；真正有差异的标记是 em-dash 与 closing fluff。同时各测试的 key-point 命中率在基线到 CLAUDE.md 之间普遍保持在 100%，说明压缩输出没有损失关键信息——这正是文档所说的"零信号丢失"。

六、决策建议：一次性任务选提示词，长期项目用 CLAUDE.md

结合profiles/RULES-IN-PROMPT.md的结论与仓库全貌，可以给出清晰的选型逻辑：

关于收益的边界，README 明确列了不适合的场景：新鲜会话频繁切换的流水线、需要保证可解析输出的场景（应改用 API 内置的 JSON 模式或带 schema 的工具调用）、以发散讨论和架构推演为主的工作（覆盖规则虽然允许显式要求，但会束缚默认行为）。这些限制同样适用于提示词粘贴方案——两种注入方式只是载体不同，规则本身的成本结构完全一致。

最后回到本文的主题：RULES-IN-PROMPT.md 提供的是"零依赖的快速注入"，CLAUDE.md 提供的是"自动化的规模收益"。两者都经过 3 个编码挑战验证（3/3 通过），差异只在钱包：提示词方案合计 $1.318，v8 方案合计 $0.935。从 benchmark/run.py 的--variant参数可以看出，这个仓库的设计本身就鼓励你把不同规则文件当作可对比的实验变量，用自己的任务跑出自己的数据，再决定长期采用哪种注入方式。