企业官网建设流程全解析

career-ops 自定义指令模板 modes/_custom.template.md 全解：让你的 AI Agent 永远遵守你的求职工作流规矩

【免费下载链接】career-opsOpen-source AI job search: scan job portals, evaluate listings into a structured A-H report with a global 1-5 score, tailor your CV, track applications — runs locally in your AI coding CLI (Claude Code, Codex, OpenCode, Antigravity…)项目地址: https://gitcode.com/GitHub_Trending/ca/career-ops

career-ops 的个性化体系把"你是谁"和"你希望事情怎么做"刻意分开存放在两个文件里：身份、叙事、薪酬目标写在modes/_profile.md，而程序性规矩（always/never 规则、命名工作流、输出偏好）则属于用户层文件modes/_custom.md。本篇以仓库中的模板种子文件 modes/_custom.template.md 为主体，完整拆解它的四个章节结构、示例规则写法、"模板→用户文件"的自动播种机制，以及 Agent 在哪些模式的哪些环节读取并执行这些规则——读完你可以直接复制一套可落地的 house rules，让规则跨会话、跨批量任务稳定生效，且不被系统更新覆盖。

一、这个文件是什么：用户层的"程序性规则"容器

modes/_custom.template.md 是modes/_custom.md的模板种子（seed）。文件开头的 HTML 注释块完整交代了它的定位与设计意图，这里逐条继承原文档的关键信息：

• THIS FILE IS YOURS. It will NEVER be auto-updated.—— 你自己的文件，永远不会被自动更新；
• 用途：存放你的 house rules、custom workflows 和 automations——任何你希望 Agent始终执行（或始终不执行）的事项；
• 职责边界：这里只写程序性规则（PROCEDURAL rules，"HOW I want things done"）。至于"你是谁"（archetypes、叙事、薪酬、谈判策略），应写入 modes/_profile.md。两者分开存放，让各自保持可读；
• 优先级：Agent 读取系统指令时会同时读取本文件；此处规则优先于默认行为，前提是不破坏 Data Contract（你的文件永不被触碰，系统也绝不会替你自动提交申请）；
• 持久性：因为是 user-layer 文件，这里写的内容可以安然通过node update-system.mjs更新流程。定制必须放在这里，而不是CLAUDE.md/modes/_shared.md等其他系统文件——后者在更新时会被覆盖。

这个定位与仓库的数据契约完全一致。DATA_CONTRACT.md 的用户层清单中明确写着：

系统层清单中则登记了modes/_custom.template.md，用途标注为"用户modes/_custom.md的模板种子"。而 update-system.mjs 源码中同时出现两条路径声明：第 140 行'modes/_custom.template.md'（系统层，随版本更新）与第 507 行'modes/_custom.md'（用户层，更新时不可触碰）。这正对应模板注释里"template 会被更新、你的_custom.md不会"的机制：更新流程用新版模板替换种子文件本身，但绝不动已生成的用户文件。

一句话分工法则（来自 AGENTS.md 的 THE RULE）：当用户要定制事实或定向（archetypes、叙事、谈判脚本、proof points、地区政策、薪酬目标）时，写modes/_profile.md或config/profile.yml；当用户要程序性 house rules、自定义工作流、输出偏好或自动化约定时，写modes/_custom.md（缺失时从modes/_custom.template.md复制）。永远不要为个人内容去编辑modes/_shared.md。

二、模板的四个章节：结构与示例规则逐节讲解

模板正文由四个 H2 章节构成，每个章节都附带 HTML 注释形式的示例，并留有一行占位提示(none yet -- add yours above)。四个章节的职责与模板自带示例原文如下：

1. House Rules（始终生效的规矩）

Agent 应该永远遵守的规则。模板注释里给出的四个示例：

• 评估摘要始终用英式英语撰写；
• CV 中永远不放照片（面向美国/ATS 优先市场）；
• 除非我另作说明，每轮 batch 最多处理 20 个职位；
• 报告评分低于 6 时跳过 cover letter。

2. Custom Workflows（命名工作流）

把经常执行的多步流程起一个短名字。模板注释中的两个示例：

• "weekly review"：扫描我关注的 portals，评估新职位，然后给我一段话总结 top 3；
• "prep <company>"：拉取 JD，基于article-digest.md生成 STAR 故事，并起草 5 个可能的面试问题。

3. Output Preferences（输出偏好）

你希望结果以什么格式呈现。模板注释中的三个示例：

• 报告：先给评分和一句话结论；
• 批量运行结束后展示分步骤的 token 消耗明细；
• PDF 文件名日期在前：YYYY-MM-DD-company.pdf。

4. Off-Limits（禁区）

Agent 永远不能为你做的事。模板注释中的两个示例：

• 未经我先确认，永不自动填写或提交申请；
• 永远不要通过编辑系统文件来定制我的配置——写在这里。

四个章节覆盖了"常驻规则 / 组合动作 / 呈现方式 / 硬性底线"四种不同粒度的指令。实际使用时不需要四节都填：Off-Limits和House Rules是约束型规则，Custom Workflows是触发型规则，Output Preferences是格式型规则——按需增删。

三、从模板到生效：doctor 自动播种与"永不报告"策略

模板不需要你手动复制。doctor.mjs 的onboardingState函数（约 L767–L788）把四个"模板→目标"映射列为冷启动状态检查的一部分，其中就包含{ target: 'modes/_custom.md', template: 'modes/_custom.template.md' }。首次运行node doctor.mjs时，若目标文件不存在而模板存在，会自动copyFileSync完成播种，并在--json输出的autoCopied字段里列出本次复制的文件（见 AGENTS.md First Run 一节对autoCopied的说明）。复制失败（例如只读文件系统）时优雅降级，留给后续检查处理。

更值得注意的是 doctor 对_custom.md的刻意沉默。doctor.mjs约 L689–L710 的PERSONALIZATION_FILES只登记了_profile.md和_brief.md，源码注释明确写道：

modes/_custom.mdis deliberately absent: it holds optional procedural house rules, so shipping it unedited is a valid end state.

原因对比很说明问题：_profile.md若不个性化，每次 A–F 评估都会用"模板作者的"archetypes 和 North Star 来给别人的 offer 打分；_brief.md不个性化则会把字面{placeholders}交给 triage 第一遍；而_custom.md不修改（保持 "(none yet)" 状态）是一个完全合法的终态——没有任何规则要遵守，恰恰就是合理的配置。因此node doctor.mjs永远不会报告它"未个性化"（AGENTS.md 也重申：modes/_custom.mdis deliberately never reported）。

四、Agent 如何读取并执行这些规则：读取顺序与覆盖点

规则写下来只是第一步，关键在 Agent 的加载链路。modes/_shared.md 的 Sources of Truth 表把_custom.md登记为 ALWAYS 读取项（路径{DATA_ROOT}/modes/_custom.md，if exists），并规定了两条硬规则：

1. 读取顺序：_custom.md在_profile.md之后读取，且在每个 mode 中都被遵守；
2. 指令性质：记录在其中的指令不是可选的，也不会在会话之间、批量任务的条目之间过期。它可以覆盖工作流/风格/程序性默认值，但永远不能引入关于候选人的事实性声明——它只是 procedural rules 的容器，不是内容来源。

AGENTS.md 的 Source-of-Truth Boundary 把这一层关系又细化了一档：modes/_custom.md属于"Primary / user-authored"信任层，但标注为"procedural/style rules only — never introduces factual claims"。也就是说它影响"怎么写、怎么排、做多少"，不影响"写了什么事实"。

具体到各模式，仓库中有多个明确的覆盖点（override hook）：

• auto-pipeline：modes/auto-pipeline.md 第 42 行——执行 A–G 评估时"读取modes/_custom.md→ Evaluation Rules（若存在）并在此应用其覆盖；缺席或沉默时：标准 A–G 评估"；
• pipeline：modes/pipeline.md 第 37 行——执行完整 auto-pipeline 前读取_custom.md→Pipeline Rules并应用覆盖；默认（缺席或沉默）为标准 pipeline 执行；
• oferta：modes/oferta.md 第 722 行——评分环节读取_custom.md→Scoring Rules并应用覆盖；默认是各 block 分数的平均值；
• pdf：modes/pdf.md 第 113 行规定生成前必须读取_custom.md并把其格式/内容 house rules 应用到本会话的每一份 CV——包括批处理中的每一份；其中记录的规则（日期格式、section 顺序偏好、总是/永不含的内容）是持久用户指令而非建议，"如果用户在对话中纠正同一件事两次，就写进modes/_custom.md，让它不再漂移"；
• email：modes/email.md 读取_custom.md，但仅限程序性输出偏好（如是否包含某些内容块）。

值得特别展开的是 modes/pdf.md 第 4 行给出的一个真实可用的 house rule 范例：pdf模式的--hm-audit（hiring-manager 审计，见 modes/pdf/hm-audit.md）默认关闭——每次运行都跑它会多花一次 subagent 调度加网络调研。开启方式有二：单次用--hm-audit标志，或在modes/_custom.md里写一条 house rule 让它对每次运行生效。modes/pdf/hm-audit.md 第 149 行再次确认："pdf.mdStep 20 只为--hm-audit运行它，或在modes/_custom.md开启后对每份 CV 运行它"。这是"用一条 markdown 规则替代一个命令行标志"的典型用法。

五、实战操作：三步建立你的 house rules

第一步：确认文件存在。运行node doctor.mjs（或node doctor.mjs --json）。若modes/_custom.md尚不存在，doctor 会从上表所列模板自动复制一份并在autoCopied中报告；onboardingNeeded只检查cv.md、config/profile.yml、modes/_profile.md、portals.yml四个必备项，_custom.md不在缺件门槛内。

第二步：按四个章节填规则。直接编辑modes/_custom.md，在对应小节下方写条目、删掉(none yet)占位行。写作建议：

• 规则用祈使句，一条一行，可验证（"用英式英语写摘要"好过"语言要地道"）；
• 给工作流起短名并写清触发条件（"weekly review：扫描 X → 评估新职位 → 一句话总结 top 3"），Agent 之后凭这个名字即可整段执行；
• Off-Limits只放你愿意让 Agent 永久放弃的能力（如"未经确认永不提交申请"——这本身就是 AGENTS.md 伦理约束的加强版，写下来等于双重保险）；
• 不要在这里写任何关于你自己经历、数字、作品的事实——那会违反"never introduces factual claims"的信任层约定，且不会进入内容生成的事实边界。

第三步：验证规则被加载。由于_shared.md规定_custom.md在每个 mode 中 ALWAYS 读取，且记录在案的指令不跨会话过期，验证方式就是日常使用：让 Agent 跑一次oferta或pdf，观察评分规则/CV 格式是否按你写的规则覆盖默认行为。若某条纠正你在对话里重复说过两次，按pdf.md的约定，把它固化进modes/_custom.md。

六、易混淆点：_custom.md与_profile.md、profile.yml、voice-dna.md的边界

career-ops 的用户层有四个"个性化"文件，职责互不重叠，放错位置会直接改变行为：

modes/README.md 的总结是：你的副本（_profile.md、_custom.md）都是 user-layer 文件；模板种子（_profile.template.md、_custom.template.md）是系统层，随更新演进；"user 定制永远进_profile.md/_custom.md，绝不进 mode 文件本身"。配合 docs/CUSTOMIZATION.md 中"谈判脚本放_profile.md（_shared.md中的脚本是示例，替换为你自己的）"的指引，边界就非常清楚：事实进 profile、人设进 _profile、流程进 _custom、文风进 voice-dna。

七、小结

modes/_custom.template.md 看似只有一份 60 行的空模板，实则是 career-ops 个性化架构里"程序性定制"的规范落点：它由 doctor.mjs 在冷启动时自动播种为modes/_custom.md，被 DATA_CONTRACT.md 划入永不被更新触碰的用户层，被 update-system.mjs 的路径表显式保护，被 modes/_shared.md 规定为每模式必读、指令不随会话过期，并在 modes/auto-pipeline.md、modes/pipeline.md、modes/oferta.md、modes/pdf.md、modes/email.md 等模式中拥有明确的覆盖点（Evaluation Rules / Pipeline Rules / Scoring Rules / 格式与内容规则）。把"always/never"写在这里，而不是散落在对话里或塞进系统文件，是让 AI 求职流水线长期稳定按你的规矩运行的最低成本方式。

【免费下载链接】career-opsOpen-source AI job search: scan job portals, evaluate listings into a structured A-H report with a global 1-5 score, tailor your CV, track applications — runs locally in your AI coding CLI (Claude Code, Codex, OpenCode, Antigravity…)项目地址: https://gitcode.com/GitHub_Trending/ca/career-ops