面试被问"你在内部有哪些 AI coding 提效工作"——只答"用了 Copilot"是最弱的回答。真正值钱的是：具体怎么用、量化结果、以及你设计的工作流。

这篇文章把我的实战拆成可复制的全链路。

六个场景，按 ROI 排序

不是所有编码环节都值得交给 AI。按投入产出比排：

1. 代码生成 —— 模板代码 / CRUD / 配置文件，提效 3-5x
2. 单元测试生成 —— 覆盖率从 40% → 80%+，省下大量机械劳动
3. Code Review —— 自动查常见问题（安全 / 性能 / 命名），压缩人工 review 时间
4. 文档生成 —— API 文档 / CHANGELOG / README，提效 5-10x
5. 调试辅助 —— 贴报错自动给修复建议
6. Onboarding —— 新人用 AI 快速理解陌生代码库

注意排序：文档和单测的 ROI 往往最高，因为它们最机械、最不依赖创造性，却最容易被人类拖延。

三层落地：个人 / 团队 / CI

提效不是装个插件就结束，要分层次铺开：

• 个人层：Cursor / Claude Code 日常编码，把重复活交给模型
• 团队层：内部 AI coding 工具 + 共享 prompt 库，把个人经验变成团队资产
• CI/CD 层：自动测试生成、自动 code review，每次 PR 触发

关键认知：不要让 AI 只在你本地跑。把它沉到 CI，才能从"个人快一点"变成"团队不出低级错"。

2026-06-26，我认真评估过用 LangGraph 重构自己的个人助理。结论是：不适合。不是 LangGraph 不好，是它解决的问题和个人助手要解决的问题不是一回事。

这篇文章不黑任何一个框架，只把"什么时候该上、什么时候是负担"的判断标准讲清楚。

先客观说 LangGraph 强在哪

LangGraph 的图（node + edge）抽象不是花架子，它解决的是可控的有状态流程：

• 多模型协作（一个节点用 GPT，一个节点用 Gemini，按条件路由）
• 分支 / 循环逻辑（审批被拒 → 回到上一节点重跑）
• 客服流程 / 审批流（需要可视化地看清楚每一步走到了哪）

这类场景里，图的好处是状态、回溯、分支都显式可调试。如果你要的是"把一段复杂业务流程跑得可控"，LangGraph 是合理选择。

我自己的 QPC 里也记下了它适合的场景：

适合 LangGraph 的场景 —— 多模型协作 / 分支循环逻辑 / 客服流程审批流

个人助手的核心诉求是另一套东西

个人助理（personal assistant）每天面对的请求，结构完全不同：

• 记忆驱动：长期记忆、工作记忆、用户偏好要持续读写
• 技能路由：80% 的请求是固定模式，不需要复杂推理，命中一个 skill 比跑一个 Agent 更稳、更便宜、更快
• 平台对接：要原生连上飞书 / Discord / 日历，而不是自己写一堆适配层
• token 优化：要持续压低上下文成本，不能每次都把整个状态图塞进去

我对比过两套方案的实际覆盖：

关键不是"谁功能多"，是个人助手的核心链路，LangGraph 一个都不原生管。

同样是稳健理财，10 万、50 万、100 万的配置重点并不一样。

资金规模越小，越要优先保证现金流和简单执行；资金规模变大后，才更值得引入多资产配置、再平衡和工具化复盘。这里讨论的是配置思路，不是产品推荐，也不构成投资建议。

10w：先解决安全垫

10 万资金最重要的是不要把系统做复杂。

如果这笔钱还承担应急、租房、家庭支出或短期计划，就不应该为了提高几个点收益牺牲流动性。这个阶段的核心目标是建立安全垫和基本纪律。

一个可思考的结构是：

• 较高比例现金或货币基金，覆盖短期不确定支出。
• 少量短债或低波动产品，用于学习净值波动。
• 暂时不追求复杂权益配置。

这个阶段最应该训练的是记录和复盘，而不是追求组合精巧。

50w：开始区分用途

50 万资金通常已经值得做用途分层。

可以把资金分成三类：

• 1 年内可能使用的钱：保持高流动性。
• 1-3 年可能使用的钱：以低波动防守资产为主。
• 3 年以上不用的钱：可以承担适度权益波动。

这个阶段可以开始建立目标比例，例如现金、短债、二级债、红利低波或宽基的组合。但比例不是重点，重点是每类资金都有明确用途。

100w：配置和流程同样重要

100 万资金的波动会更有体感。

组合回撤 5%，账面就是 5 万；回撤 10%，就是 10 万。这个阶段不能只看“年化收益”，必须把最大回撤、再平衡规则和极端行情预案写清楚。

已有的《100w 稳健型基金组合 · 执行手册》就是一个实战样例：先定义本金、目标年化、最大回撤和再平衡周期，再拆成具体资产类别。

三档资金的差异

资金越大，越需要流程。不是因为大资金一定要复杂，而是因为错误决策的绝对金额更大。

不同规模都需要的底层规则

无论资金规模多大，都应该先写清楚：

• 哪些钱不能亏，哪些钱可以承担波动。
• 最大可接受回撤是多少。
• 每类资产的目标比例和允许偏离区间。
• 多久复盘一次。
• 什么情况下必须停止新增风险资产。

如果这些规则没有写下来，资金规模越大，情绪化操作的代价越高。

工具化从 50w 后更有价值

10 万阶段，一个简单表格就够。

50 万以后，可以开始记录目标比例、当前比例、偏离值和复盘备注。100 万以后，再平衡提醒、公告摘要、组合归因和月度报告就会更有价值。

工具化不是为了炫技，而是为了减少漏看、少算和冲动决策。

1GB VPS 可以跑个人助理智能体，但前提是别把它当大服务器用。

低资源环境最重要的是克制：少进程、少常驻、少浏览器、少后台任务。部署前就要想清楚哪些功能必须在线，哪些功能可以按需运行。

部署前检查

先确认资源边界：

• 内存是否约 1GB。
• 是否有 swap。
• 磁盘空间是否足够日志和依赖。
• 系统是否开启自动安全更新。
• SSH 登录是否使用密钥。
• 防火墙是否只开放必要端口。

如果机器本身不稳，不要急着部署 Agent。

功能裁剪

个人助理在 1GB VPS 上应该优先保留核心链路：

• 消息入口。
• 模型网关或 API 调用。
• Skill 路由。
• 少数必要工具。
• 轻量记忆或知识库。
• 日志。

可以延后或禁用：

• 浏览器自动化常驻服务。
• 大型向量数据库。
• 多 Agent 并发编排。
• 语音转写和合成。
• 重型监控面板。

功能越少，系统越容易稳定。

部署中检查

部署时按顺序验证：

1. 服务能启动。
2. 入口能收到消息。
3. 模型调用能返回。
4. Skill 路由能命中。
5. 工具调用能成功。
6. 记忆写入和读取正常。
7. 日志能落盘。
8. 服务重启后状态可恢复。

不要等全部部署完才第一次测试。

安全检查

个人助理通常握有 API Key 和个人数据，安全边界要提前做。

检查项：

• 密钥不写进仓库。
• 配置文件权限收紧。
• 面板不直接暴露公网。
• 反向代理路径不可预测。
• 高风险工具默认关闭。
• 日志不打印完整密钥。
• 远程命令需要人工确认。

低资源不是降低安全要求的理由。

部署后检查

上线后观察 24 小时：

个人知识库最大的问题通常不是容量，而是维护摩擦。

字段越多，写入越慢；分类越复杂，越容易放弃。QPC 的价值是把知识记录压缩到足够小，让个人助理能稳定写入和检索。

QPC 是什么

QPC 可以理解为四类知识：

• Question：问题。
• Practice：实践。
• Concept：概念。
• Fact：事实。

它不追求一次性建成完整知识图谱，而是先把值得重读的信息记录下来。

为什么适合个人助理

个人助理经常遇到可沉淀的信息：

• 某个命令为什么失败。
• 某个配置项是什么意思。
• 某个项目的默认路径。
• 某次排障的解决步骤。

这些信息不一定值得写成长文，但值得下次能找到。

四字段降低摩擦

一个 QPC 条目可以很简单：

字段少，Agent 才能稳定写。

和长期记忆的关系

QPC 不等于全部记忆。

偏好、任务状态、配置事实和知识条目可以分层存储。QPC 更适合保存可复用知识，而不是当前任务里的临时上下文。

检索比分类更重要

个人知识管理不应该把精力花在完美分类上。

只要标题清楚、内容紧凑、来源明确，后续通过搜索或 Agent 检索就能找回来。QPC 的核心是降低写入成本，让知识真的留下来。

个人助理的很多任务，不需要重新发明推理过程。

“写博客”“记一条知识”“查服务器状态”“生成月度复盘”“整理配置”这些任务都有明确流程。如果每次都让 Agent 从零思考，很容易出现不稳定输出和错误工具调用。

Skill 路由的思路是：先识别任务场景，再进入对应流程。

ReAct 的问题

ReAct 循环适合开放探索，但个人助理的大多数任务不是开放探索。

无约束循环可能带来几个问题：

• 过度思考简单任务。
• 选择不相关工具。
• 重复尝试已经失败的动作。
• 在缺少信息时硬编下一步。
• 难以复盘为什么走到某个结果。

对个人助理来说，可控性往往比“看起来聪明”更重要。

Skill 的价值

Skill 把任务流程显式化。

一个好的 Skill 至少说明：

• 什么时候触发。
• 需要哪些输入。
• 可以调用哪些工具。
• 输出应该是什么格式。
• 失败时如何降级。
• 哪些动作需要人工确认。

这会显著减少不确定性。

命名要贴近场景

Skill 名称应该让人一眼知道它处理什么任务。

例如：

• hugo-blog：写博客、编辑文章、构建部署。
• qpc：记录和检索个人知识。
• ssh-git-vps-deploy：处理 VPS 上的 Git 部署。
• x-ui-and-new-api-security-posture：处理特定安全加固场景。

名称越具体，路由越稳定。

触发词要具体

触发词不应该太宽。

“工具”“处理”“帮我看看”这类词太泛，容易误触发。更好的触发词是和场景强相关的词，例如“写博客”“QPC”“部署到 VPS”“检查 x-ui 安全”。

个人助理可以允许多个触发词，但每个触发词都应该指向明确任务。

输入输出边界

每个 Skill 应该定义输入和输出。

例如博客 Skill 的输入可以是主题、标题、目标读者、已有素材；输出是文章文件、构建结果、提交状态。

QPC Skill 的输入可以是一段知识或检索问题；输出是结构化记录或匹配结果。

输入输出清楚，Agent 就更少临时发挥。

失败时要降级

Skill 还应该说明失败时怎么办。

例如：

• 找不到文件：先搜索仓库，不要编路径。
• 构建失败：报告错误，不要推送。
• 权限不足：停止并说明需要人工操作。
• 信息不足：提出缺失字段，而不是生成假答案。

降级策略是个人助理可靠性的关键。

如果不分类，Agent 失败看起来都像“模型不行”。

但个人助理的失败来源很多：理解错、路由错、工具错、记忆错、权限错、环境错、恢复错。分类之后，才能知道该修模型、修 Skill，还是修工具。

七类失败

这张表比一句“Agent 崩了”更有排查价值。

先定位再修复

不要看到失败就改 prompt。

如果是工具参数错，应该修 schema 或校验；如果是路由错，应该修触发词；如果是权限错，应该修确认机制；如果是环境错，应该修部署和监控。

错误分类能避免把所有问题都甩给模型。

日志字段

每次失败至少记录：

• 用户请求。
• 命中的 Skill。
• 调用的工具。
• 错误类型。
• 错误信息。
• 是否重试。
• 是否需要人工处理。

这些字段足够支持月度复盘。

复盘动作

失败复盘可以只问三个问题：

1. 这类失败是否重复出现？
2. 它能否通过规则或校验提前拦住？
3. 它是否需要加入 QPC 或维护手册？

个人助理的可靠性来自持续修小错，而不是一次性设计完美系统。

个人助理智能体一旦接入真实工具，就会碰到安全问题。

密钥、Web 面板、API 网关、反向代理、远程命令都可能成为风险点。精简个人助理不是少做安全，而是减少暴露面。

密钥

密钥不应该写进仓库、文章、日志或普通聊天记录。

Agent 可以检查配置项是否存在，但不应该完整打印 token。写技术文章时，也应该使用脱敏结构和真实字段名，而不是暴露真实值。

面板

Web 面板不应该直接裸露公网。

至少要有认证、不可预测路径或访问限制。默认路径、弱密码和公开端口会让个人项目承担不必要风险。

网关

API 网关负责把请求转给模型或工具。

网关要限制来源、记录调用、保护密钥，并避免把内部错误直接暴露给外部。能只开放一个入口，就不要暴露多个入口。

日志

日志需要足够排障，但不能泄露秘密。

不要记录完整 Authorization header、API key、cookie、个人账户信息。可以记录脱敏摘要、请求类型和错误码。

高风险动作

以下动作必须人工确认：

• 修改认证配置。
• 暴露新端口。
• 修改反向代理。
• 删除配置或日志。
• 执行远程命令。
• 写入生产数据。

安全边界要默认保守。

检查清单

• 密钥是否只存在于安全位置？
• 面板是否有认证？
• 网关是否限制来源？
• 日志是否脱敏？
• 高风险工具是否需要确认？
• 是否有回滚方式？

个人助理越强，越要把权限和安全写清楚。

个人助理智能体不需要一开始就有复杂平台。

一个最小可用架构，只要能稳定完成“理解请求、选择流程、调用工具、记录结果、必要时请人确认”这条链路，就已经能解决很多实际问题。

架构图

入口：只负责接收请求

入口可以是聊天窗口、飞书消息、命令行或 Webhook。

入口不应该承担复杂逻辑。它只需要把用户请求、用户身份、时间和上下文传给后面的处理链路。

这样以后更换入口时，不需要重写核心逻辑。

模型路由：按任务选择模型

不是所有任务都需要最强模型。

个人助理越有用，权限越敏感。

它可能能读文件、写博客、调用 API、访问服务器、发送消息。如果没有权限边界，一个小错误就可能变成真实损失。

权限设计的目标不是让 Agent 什么都不能做，而是让每类动作都有合适的确认级别。

四类权限

我倾向于把权限分成四类：

默认从只读开始，逐步增加权限。

文件系统

文件系统权限最常见，也最容易被低估。

读取通常风险较低，但也可能涉及隐私。写入、覆盖、移动和删除都应该更谨慎。

规则可以是：

• 读仓库文件：允许。
• 写新草稿：允许。
• 修改已有配置：先说明影响。
• 删除文件：必须确认。
• 递归删除：必须确认并验证路径。

远程命令

远程命令必须保守。

查看状态、读日志、检查磁盘可以是只读。重启服务、修改配置、拉取代码、执行迁移都可能影响线上状态，应该要求确认或至少先展示命令和影响。

不要让 Agent 在不解释的情况下执行远程破坏性命令。

密钥和配置

密钥不应该进入普通对话和公开日志。

Agent 可以检查“是否存在配置项”，但不应该完整打印密钥。写文章时也只能引用脱敏结构，不应该暴露真实 token。

配置修改需要记录：

• 修改前是什么。
• 修改后是什么。
• 为什么修改。
• 如何回滚。

面板和网关

Web 面板、API 网关和反向代理是常见暴露面。

个人助理可以辅助检查端口、路径和访问控制，但涉及开放公网、修改认证、变更代理规则时必须人工确认。

安全配置的错误往往不是马上爆炸，而是留下长期风险。

确认机制怎么写

高风险动作前，Agent 应该给出：

将要执行的动作：
影响范围：
是否可回滚：
回滚方式：
需要你确认的命令或选项：

确认不是形式主义。它迫使系统把隐含风险显式化。

最小权限是默认值

个人助理长期可用的前提，是你能放心让它运行。

如果一个能力无法安全地设定边界，就不要急着接入。能只读就只读，能建议就建议，真正需要执行时再让人确认。