实用提示：让 Claude Code 成为得力助手的5种MCP连接方式

以下内容为围绕“5种能让Claude Code成为首席幕僚的MCP连接方式”所设计的实用路径。重点在于契约、校验机制以及可直接插入的代码占位符，而非激励性表述。

第一部分介绍了针对文件的处理流程。这一部分则将智能体集成到日历、Slack和电子邮件系统中，从而能够处理实时数据。

在实施第一部分所述的处理流程时，首先需明确契约内容：所需输入、成功标志以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。同时要在功能结果旁记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外账单。

每次调用后都要记录工具名称、参数哈希值、延迟时间以及最终结果。没有这些记录，调试智能体循环将会耗费大量时间。

claude mcp add <name> <command or URL>

1. 熟悉日程的晨间简报

在处理“晨间简报”阶段时，首先写下相关合同条款：所需输入、成功标志以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 将配置信息置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放，这样操作人员无需查看整个系统结构即可进行审计。 为每次调用记录工具名称、参数哈希值、延迟时间以及最终结果。没有这些记录，调试代理将陷入无止境的循环，浪费大量时间。

---
description: Morning briefing from calendar plus notes
---

Read today's and tomorrow's calendar events.
Read my notes from the past 7 days in notes/.
Read projects/ for anything with a deadline this week.

Produce a briefing:
- Today's schedule, with a one-line "what you need for this" per meeting,
  pulled from my notes where relevant
- Conflicts, back-to-backs, or meetings with no clear purpose
- The one thing that deserves my best two hours today, and why

Under 300 words. Do not create, move, or edit any events.

2. 不用滚动即可查看聊天应用消息

在实现“2. 即时补足”功能时，首先写下相关契约：所需的输入参数、成功标志以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及死信处理都是产品本身的组成部分，而非后续需要补充的功能。 为每次调用记录工具名称、参数哈希值、延迟时间以及最终结果。没有这些记录，调试代理将陷入无止境的循环，耗费大量时间。

Read the past 2 days of messages in #team, #project-atlas, and
any thread I was mentioned in.

Summarise:
- Decisions made (with who made them)
- Questions directed at me that I haven't answered
- Anything that changed a deadline, scope, or owner
- Threads still on fire

Link each item to the message so I can jump in. Do not post,
react, or reply to anything.

3. 自动化处理电子邮件收件箱

在完成“实现邮件自动化”的三个阶段时，首先列出相关约定：所需输入、成功标志以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 优先选择小型、可测试的单元，而非庞大的脚本。当某个步骤失败时，故障应能指向单一责任模块，而非复杂的流程链。 为每次调用记录工具名称、参数哈希值、延迟时间以及执行结果。没有这些记录，调试代理循环会浪费大量时间。

Read unread email from the past 3 days.

Sort into:
- Needs a reply from me (draft one, save to drafts/, do NOT send)
- Needs an action but not a reply (list the action)
- FYI only (one-line summary each)
- Ignorable (just count them)

Never send, delete, archive, or mark anything. Drafts stay drafts.

4. 自动更新的任务看板

在处理“自我更新任务”的四个阶段时，首先需写下契约：所需的输入、成功信号以及部分失败时的处理方式。这份清单能确保后续的代码修改始终符合约定。 将这一阶段视为输入与验证后输出之间的契约。为相关产物命名，明确成功判定标准，杜绝默许的部分完成情况。 需记录每次调用的工具名称、参数哈希值、延迟时间以及最终结果。没有这些记录，调试过程将会浪费大量时间。 在处理“自我更新任务”的四个阶段时，首先需写下契约：所需的输入、成功信号以及部分失败时的处理方式。这份清单能确保后续的代码修改始终符合约定。 应将配置信息置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放于一处，这样操作人员无需查看整个系统结构即可进行审计。

---
description: Reconcile the project board with reality
---

Read the project board.
Read my notes and logs from the past 7 days.

Find the drift:
- Tasks marked in-progress that my notes say are done
- Work my notes describe that has no ticket at all
- Tickets untouched for 14+ days

Propose the updates as a list. On my approval, apply them.

5. 全面搜索！

“全面搜索”阶段若被视为可度量的对象，效果会最佳。在扩大范围之前，先记录一个成功的用例、一个失败案例以及回滚说明。同时将正常流程和恢复流程都记录下来。重试机制、人工审核环节以及死信处理都是产品本身的一部分，而非后续需要补充的内容。应提供具有明确结构定义和清晰副作用标识的工具，这样主机在自动批准之前就能知道哪些调用会改变状态。

---
description: Weekly review across every connected source
---

Read: this week's calendar, my notes/, the project board,
Slack decisions in #team, and my sent email from the past 7 days.

Produce the week:
- What shipped, versus what the week was supposed to be about
- Decisions made anywhere (notes, Slack, email) that never made it
  to the board or my notes
- Commitments I made in email or Slack that have no task attached
- Next week's real priorities, based on all of the above

Write to reviews/YYYY-WW.md. Flag anything you inferred rather
than found.

该模式（再次介绍）

将该流程视为可测量的界面时，其效果最佳。在扩大范围之前，先记录一个成功的案例、一个失败案例以及回滚说明。相较于庞大的脚本，应优先选择小型且可测试的单元。当某一步骤失败时，故障应指向单一责任点，而非复杂的流程链。需使用结构明确的工具，并标注清晰的副作用信息。主机在自动批准之前必须知道哪些调用会改变状态。

操作检查清单

在操作检查清单阶段，修改代码之前需明确输入参数、该步骤的负责人以及完成标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏的状态。

在功能结果旁记录处理时间以及令牌或查询成本。提前了解成本情况，可避免在系统从演示环境切换到共享环境时出现意外账单。

在网关处进行身份验证，在数据层进行重新授权。仅凭承载令牌并不能作为租户边界。

编写简短的操作手册：说明如何轮换密钥、如何清空队列、以及如何回滚上一次的数据导入操作。

将配置信息置于应用程序代码之外。环境文件、密钥存储和功能开关应集中存放于一个位置，以便操作人员无需查看整个系统结构即可进行审计。

在网关处进行身份验证，在数据层进行重新授权。仅凭承载令牌并不能作为租户边界。

在推广该技术栈之前，应先冻结版本、为关键流程记录标准输出日志，并明确回滚步骤。共享环境需要设置速率限制、租户验证机制，以及负责密钥轮换的明确责任人。与其展示花哨的一次性演示，不如追求扎实可靠的性能。

a0d364d17aa1的批处理说明：不要将提供商密钥放入代码仓库，为每个会话设置令牌使用上限，并将日志存储在评估用示例文件旁，以便后续模型更换时保持对比一致性。