企业官网建设流程全解析

上个季度我接了一个内部工具改造的活儿：一个后端服务需要借 Claude Code 做代码生成和批量重构。前期跑 Demo 很顺，提示词写一版就过，生成代码也能跑通，团队一度觉得马上就能省下大把人力。结果进入真实项目的第二天就翻了车——同样的任务，上午跑得好好的，下午生成结果开始随机抽风；同一段逻辑换个文件路径就理解错；最要命的是，一个下午四个人的团队烧掉了平时一个月都烧不完的 API 账单。

后来复盘时发现，问题并不出在 Claude Code 本身，而是我们把它当成一个“一次问、一次答”的对话工具在用，完全没有给它的输出加质量校验，也没有管理它在长任务里的记忆边界，更不要说对 token 成本做任何约束。

这也是我看到 Verity.md 这个项目标题时，觉得值得认真聊一聊的原因。它做的事情非常聚焦：quality gates、memory、cost control，恰好是 Claude Code 从小玩具走向生产工具时最容易被忽略，也最容易翻车的三块短板。

1. 先搞清楚这个工具真正解决的是哪类重复劳动

Claude Code 这类 CLI 编程工具，核心价值不是把“谷歌一下代码怎么写”变成“问 ChatGPT 一行”，而是把重复性极高的编码劳动自动化。比如迁移一个旧模块、给几百个函数补注释、按统一规范重命名变量、把一个 API 的调用方式批量改掉。这类任务的特点是：规则清晰、样本量大、人工做容易疲劳。

但问题是，Claude Code 默认只是一个对话式 Agent。你给它一个任务，它会基于上下文生成一段结果，然后你“哦”一声，发现能用就收下，不能用就让它重跑。这个过程单次看没问题，一旦放到真实项目里，三个非常现实的问题就会出现。

第一个问题是没有质量门禁。Claude Code 不是一个编译器，它生成完代码，不会自动替你跑测试、查 lint、检查依赖是否越权。它给你一个“看起来合理”的结果，但“看起来合理”和“确实能通过质量检查”是两码事。一旦任务规模变大，人工检查的质量本身就不可靠，你必须把检查变成一条自动化的门禁规则。

第二个问题是记忆过于碎片化。Claude Code 在单个会话内部能记住上下文，但跨会话、跨长任务、跨分支场景几乎不保留任何项目级记忆。你今天告诉它“这个项目使用 pnpm，不要用 npm”，明天开新的会话它照样可能给出一堆 npm 命令。除非你愿意一遍一遍地在每个会话开头重复项目背景。

第三个问题更隐蔽，就是成本完全失控。Claude Code 在长任务里会不断积累上下文，token 消耗不是线性增长，而是像滚雪球一样膨胀。你以为自己只发了 5 条指令，实际它内部可能在反复读写大量文件、重推多轮上下文。等到月末账单出来，才发现模拟了一个循环，钱也烧完了。

Verity.md 这个项目，从命名就能看出它的目标：它想把这些散落在工程实践里的检查、记忆、成本约束集成到 Claude Code 的工作流里。它不是要替代 Claude Code，而是要给它装上“安全护栏”。

注意：如果只是个人写个小脚本，Claude Code 默认行为完全够用。真正需要 Verity.md 这类工具的场景，是任务量大、输出需要被复用、成本需要被预算约束的工程化环境。

1.1 从“回答正确”到“结果可信”，差了一条门禁

很多刚接触 Claude Code 的人会误以为：模型越强，生成代码就越不需要检查。这个想法在玩具项目里没问题，在真实项目里非常危险。

我见过最典型的翻车现场：同事让 Claude Code 重构一个文件，生成结果通过了单测，但代码里偷偷引入了一个对错误模块的 import，这个 import 在自己的机器上能跑，推到 CI 因为环境变量不同直接挂掉。又比如它生成了一段递归逻辑，本地数据量小的时候没问题，等数据量涨到几千条直接栈溢出。这些问题单靠读代码很难发现，必须运行检查、静态分析、依赖审计才能在早期拦住。

所以 quality gates 的本质，不是“让 AI 生成更正确”，而是“让不正确的生成结果无法进入你的代码库”。传统工程化里这叫 CI 门禁，放到 AI 编程场景里就是：AI 生成完代码之后，自动执行一组预设校验，比如语法检查、单元测试、lint、类型检查、构建验证，校验不通过就自动触发修复或告警。

Verity.md 想要做的，就是把这类门禁搬进 Claude Code 的生成流程里，让你在写提示词的时候就可以声明“生成结果必须通过这些检查”。这样一来，生成不再是一次性的“赌概率”，而变成可重复的、有反馈闭环的流程。

1.2 为什么过去这个问题不好解决

如果没有专门的工具，你其实也能手动给 Claude Code 加门禁：生成完代码之后，自己跑一遍 pnpm lint、pytest、mvn test，发现问题再复制回会话里让它修。但这个流程有两个致命问题。

一是操作成本高。你必须不断在编辑器、终端、聊天窗口之间来回切换，手工搬运报错信息。人一累就容易偷懒，偷懒就会跳过检查，跳过检查前面省的时间全部白省，后面还要用三倍时间补。

二是反馈时效差。你等生成完一整段代码才去检查，发现问题时它已经跑偏了很远。AI 修复后面的错误时，可能又会改坏前面已经对的部分。这就是为什么理想中的质量门禁应该是“小步快跑”的：每生成一小段，就自动跑一次检查，把偏差控制在最小范围内。

Verity.md 这类工具的逻辑就是把这个过程自动化：门禁规则由用户定义，由 Claude Code 在生成过程中自动执行。你不需要手动跑测试，测试失败信息会直接作为上下文喂回到模型里，模型在此基础上做修正。

1.3 质量门禁需要避开什么坑

我自己的经验是，给 Claude Code 配置质量门禁，最容易踩的坑是“规则定得太死，导致大量误报”。

比如你要求每段代码都 100% 通过 pylint 且 0 warning，这在老项目里几乎不可能，因为存量代码本身就有大把历史告警。AI 为了满足你的要求，可能用奇怪的写法绕过 lint 规则，或者干脆重写别的模块来“凑干净”。这比你本来想解决的问题更糟。

更合理的做法是：门禁规则先覆盖“阻断型”项，再覆盖“质量型”项。

• 阻断型项：语法错误、类型不匹配、关键单测失败、依赖越权。
• 质量型项：代码风格、命名规范、行长度、注释完整性。

质量型项更适合作为“建议”，而不是“必须通过”。你要给 AI 留出判断空间，门禁的作用是防止灾难，而不是追求完美。

2. 记忆管理：Claude Code 记不住的东西，谁来替它记

用过 Claude Code 长一点时间的人，都会遇到一个很熟悉的困境：会话刚开始时它表现很聪明，到了上下文接近上限时开始“失忆”，把你早期说过的约束忘得一干二净。

这不是模型变笨了，而是上下文窗口是有限的资产。一旦超过上限，旧信息就会被截断或压缩。Claude Code 自带的机制是在单次会话结束时输出一个 CLAUDE.md 文件，里面记录你希望它在未来会话中遵守的规则。这个思路很好，但真正用起来，很多人会发现两个问题。

第一个问题是更新不及时。CLAUDE.md 写完之后很少被主动维护，项目演进到第三周，里面的规则还停留在第一周的状态。AI 拿着过时的规则干活，自然容易出错。

第二个问题是粒度太粗。项目级规则写在一个文件里，但不同模块、不同任务需要遵守的规则可能完全不同。一个文件塞不下所有细节，也容易互相矛盾。

Verity.md 的 memory 能力，从项目定位来看就是把记忆从“一次性会话”提升到“项目级持久化”。它的价值不是帮你写 CLAUDE.md，而是把“项目背景、决策记录、约定规范、历史失败经验”这些碎片信息，变成 Claude Code 在生成代码时可以主动参考的资产。

2.1 会话记忆、项目记忆和长期记忆是三种不同的事

把 AI 编程里的“记忆”拆开看，至少有三层：

• 会话记忆：模型在本次对话里记住你说过什么。优点是零配置，缺点是会话一关就清空。
• 项目记忆：跨会话保持，描述项目的背景、技术选型、代码风格、目录结构。需要人工写入文件，但可以被长期复用。
• 长期经验记忆：你这次踩过的坑、找到的最佳实践，沉淀下来以后遇到同类任务直接复用。

Claude Code 自带的 CLAUDE.md 帮你解决的是第二层，第三层基本靠人自觉维护。Verity.md 这类工具想统一做的，就是让这层记忆不被丢在聊天记录里，而是沉淀成项目可直接查询的上下文。

排序一下优先级，我建议任何用 Claude Code 做真实项目的团队，都先把第二层做扎实。第三层可以逐步积累。第一层不用管，那是模型机制天然支持的。

2.2 记忆文件怎么组织，才不会被 Claude Code 忽略

很多人的 CLAUDE.md 写得跟公司管理制度一样，一条一条列得很全。问题是，AI 不是按顺序读完就强制执行，上下文窗口有限，它只会取它认为相关的部分。你写几千字规则，它可能只挑了其中 20% 来用。

从工程经验看，更有效的记忆文件结构是“入口文件 + 按模块拆分”：

• 根目录放一个CLAUDE.md，只写最高频、最通用、最不能错的规则。
• 每个子模块或子任务目录下放独立的规则文件，比如docs/CLAUDE.module.md。
• 在根文件中用明确路径告诉 Claude Code：具体模块规则去哪个文件找。

这样 Claude Code 在决定一个任务时，能按模块精确读取对应记忆，而不是在几千字的全局规则里大海捞针。

2.3 记忆管理的核心不是存储，而是“动态更新”

最容易让人产生误区的是，以为把规则写下来就算完成记忆管理了。真正让记忆有价值的，是它能不能随项目变化而更新。

我见过一个做法值得参考：把 Clauude Code 修复过的 bug 案例记录成一个failure_cases.md文件，每次遇到类似问题，AI 可以先参考历史失败经验。这个习惯一开始很费事，但积累两三周之后，模型在这类项目里的表现会明显稳定，因为它有了“从失败中学习”的参照物。

Verity.md 如果做得够好，它应该让这类记录和引用变成自动化的：完成任务时自动追加关键决策和结果，新会话开始时自动注入相关历史记录。这个方向对长项目、多人协作项目尤其有价值。

3. 成本控制：被很多人忽略，却是真实项目存活的前提

如果说质量门禁和记忆管理是“让结果变好”，成本控制就是“让结果可持续”。

在 Claude Code 的生态里，成本不是一个静态的数字。它取决于模型价格、任务复杂度、上下文长度、重试次数、输出长度多个因素。同样一个任务，不同人写提示词的效率差别可以到 5 到 10 倍，账单上的数字也跟着水涨船高。

最容易烧钱的行为包括：

• 让 Claude Code 反复重读大量无关文件，比如把它不需要了解的整个日志目录、node_modules 里的内容放进上下文。
• 任务描述模糊，模型反复猜、反复试，每次试错都要消耗输入和输出 token。
• 单元测试失败后，AI 盲目修改，修改一次跑一次，跑一次又失败，进入“修复循环”，而每一轮都在花钱。
• 没有成本下限和上限，一批任务丢进去跑一晚上，第二天看到账单才后悔。

3.1 Claude Code 的成本从哪里来

要控制成本，先理解 Claude Code 的 token 消耗结构。它不是一次性请求全部输入，而是在一个会话里逐步累积上下文。任务越长，上下文越大，后续每轮请求的 input token 都会变多。

可以这样理解：你让它处理 10 个文件，最开始可能只输入 2 个文件的内容。可一旦上下文窗口里堆了 10 个文件的历史结果、错误信息、修改记录，后续每次模型调用，它都需要重新处理这 10 个文件的内容。哪怕你只是让它改一个小变量，也要付前面所有累积上下文的钱。

这就是为什么 Claude Code 跑长任务的成本会指数级上升。不是模型变贵了，而是上下文里的“历史包袱”越来越重。

很多人的省钱策略是“少说几句、让它自己发挥”，但这对长任务几乎无效。真正有效的策略是管理上下文输入：

• 明确指定输入文件路径，不要让它自己翻目录。
• 无关文件通过.claudeignore排除在外。
• 拆成多个短任务，每个任务只包含它需要的最小文件集合。
• 单个任务结束之后不要继续追加新需求，重新新开会话。

Verity.md 这类工具在 cost control 上的思路，应该就是把这类约束变成自动化的：在任务启动前评估要读取的文件清单，在任务过程中监控上下文大小和 token 消耗，在接近预算上限时自动分割任务或触发提醒。

3.2 先跑通、再批量、后优化，是成本控制的第一原则

关于节省 token，我看到很多人的第一反应是“找一个更便宜的模型”。这听上去合理，实际落地很可能是灾难：便宜模型在复杂代码任务上失败率更高，失败后重试的次数增加，最终总成本反而更高。

更稳妥的成本控制路径是：

1. 用一条最简样例跑通主流程，确认输入输出都符合预期。
2. 用一个小批量（比如 3 到 5 个样例）验证稳定性。
3. 再扩大到完整数据集，同时设置预算下限和上限。
4. 跑完后分析日志，看看 token 消耗在哪一步最高，再做针对性优化。

这个方法适用于任何用 Claude Code 做批量任务的场景。你要先知道任务在什么精度、什么成本水平下可用，才能决定要把它交给哪个模型、怎么配置参数。

3.3 成本预算的合理阈值怎么定

预算不是设一个总数那么简单，要按任务粒度拆分。常用做法是：

• 单任务预算上限：比如一个文件的重构最多烧 10000 token，超出自动暂停。
• 单会话预算上限：比如一轮会话最多烧 80000 token，提醒是否继续。
• 每日预算上限：用于团队共享账号时避免单个成员的操作烧掉整个团队额度。

在 Verity.md 这类工具里，成本控制的理想形态是“按任务声明预算”，而不是事后看账单。任务开始前你可以声明这个任务值得花多少 token，超过就想办法节省成本，比如切换模型、缩小输入范围、简化输出格式。

4. 真正的落地方式：先从最小可用流程开始，再往工程化靠近

写了这么多，最后落到落地层面。Verity.md 如果要放进真实的 Claude Code 工作流，我更建议一步一步来，不要一开始就追求全上。

很多人的误区是：看到一个工具能解决三个问题，就想着一次性把所有规则都配齐，然后正式跑项目。结果你花了一整天配置规则，第二天发现问题比预期复杂，又把规则改回默认值。这个循环非常磨人。

更理性的做法是分三个阶段推进：

阶段一：先跑门禁。选一个任务量适中、失败成本较低的模块，把最基本的通过条件写好，比如“必须通过语法检查”“必须通过已有单测”。先不要加太多规则，目标是确认门禁能拦住明显错误。

阶段二：再管记忆。把项目的技术栈、目录结构、常用命令、编码规范写进记忆文件。新开一个会话，故意测试模型是否遵守。如果它没遵守，检查记忆文件的组织方式是不是太乱、太泛。

阶段三：最后控成本。已经积累了足够多的任务样本，能估计出单个任务的 token 消耗区间。这时候再设预算阈值，才有参考数据。如果一步到位直接设一个很低的预算，大概率会让任务频繁被截断，体验很差。

4.1 什么样的人适合用这类配置

从定位来看，Verity.md 最适合三类人：

• 用 Claude Code 处理批量重构、批量迁移、批量文档生成的开发者，需要稳定控制输出质量。
• 团队内多人共用同一个 Claude Code 环境，需要统一规范和统一成本边界。
• 长期维护一个大型代码库，希望 model 不只“能生成”，还要“懂项目背景”。

如果你只是偶尔用 Claude Code 写一两个脚本，或者当前项目处于探索阶段，还没决定技术方向，这类工具的价值不大。先让模型自由发挥，先把任务跑通，比严格约束更有意义。

4.2 落地时最容易出问题的地方

从我自己的经验看，落地这类工具时最容易出问题的环节有四个：

1. 配置文件始终没生效。Claude Code 的配置有时需要放在特定目录、命名成特定文件名。如果项目结构复杂，比如 monorepo，根级配置和子目录配置的覆盖顺序要搞清楚。
2. 门禁规则和项目现状冲突。老项目里 lint 规则常年积累，你想让 AI 生成结果“零告警”，但现有代码本身就是“满屏告警”。合理化做法是门禁规则只针对新增生成结果，不要要求存量代码也清零。
3. 记忆文件太大，模型读取效率下降。规则多、文件长不一定是好事。模型处理长记忆时会占用大量上下文预算，反而挤占了真正需要专注的任务内容。
4. 成本控制的粒度不对。如果预算设得太粗，比如只设一个月度总额，那它只能起到事后提醒的作用。预算应该设在任务级或会话级，才能在执行中拦截。

4.3 一份可以直接参考的配置检查顺序

如果准备尝试，建议按照这个顺序做第一次配置：

1. 确认 Claude Code 当前版本和依赖环境，记录版本号，避免后面升级导致配置行为变化。
2. 看官方文档对配置文件的说明：放哪里、叫什么名字、支持什么字段。
3. 先写一个最简的 validation 规则，比如“生成结果必须包含一个 main 函数”，跑一条任务验证是否触发。
4. 再增加语法检查、单测、依赖检查等真实门禁。
5. 写项目记忆文件，从高频规则开始，每条规则尽量短、明确、可测试。
6. 最后加 token 预算，先用小样本估算单任务平均消耗，再按平均值乘以 1.5 到 2 倍设置单次预算上限。

注意：不要一上来就把批量数和并发数拉满，先用一条样例确认输入、输出和日志都正常。

5. 从“能用”到“好用”，差的不是模型能力，是工程护栏

回到文章开头那个真实案例。后来我们把 Claude Code 重新接入项目时，做的第一件事不是找更强的模型，也不是调更多提示词，而是先解决三个基础问题：

• 生成结果必须过检查，不再人工肉眼看代码。
• 项目规范写进记忆文件，每个会话都默认继承。
• 批量任务设好预算边界，防止一个任务烧穿整月账单。

这些东西做起来不炫酷，甚至有点琐碎，但正是这些琐碎的工程护栏，决定了 AI 编程工具能不能从“偶尔用一次”变成“每天都在用”。

我理解 Verity.md 想要卡的位置，就是在 Claude Code 和真实项目之间，加一层工程化的治理层。它不改变模型的推理能力，也不改变提示词技巧，而是改变你使用 AI 编程工具的方式：从一次性的、随意的、不可控的对话，变成有门禁、有记忆、有预算的工程流程。

这和传统软件开发里的演进是相似的。早期你写 Python 脚本，不需要 CI、不需要依赖锁定、不需要配置管理；直到代码库变大、多人协作、需要部署上线，你才意识到光有“代码能跑”远不够。AI 编程也一样。个人玩具可以裸奔，真实项目必须有护栏。

如果你的项目已经进入“每天依赖 Claude Code 做真实任务”的阶段，那么无论是否用 Verity.md 这个具体项目，都应该认真考虑把质量门禁、记忆管理和成本控制这三件事补上。哪一件先做，取决于你当前最痛的点在哪里。但最终，这三样都会成为 AI 编码工作流里的标配。