研发工程师在工作中如何使用 Claude？

Paid_AI_circle

29人浏览 · 2026-07-29 09:49:14

Paid_AI_circle · 2026-07-29 09:49:14 发布

写在前面：我在金融行业做了几年，前半程写交易系统和风控中台，后半程主要泡在量化研究和策略工程化里。团队里既有做因子研究的 researcher，也有维护低延迟撮合链路的 C++ 工程师，还有一堆写 Python 胶水、干数据管道的人。这篇东西不打算讨论”AI 会不会取代程序员”这种没什么信息量的问题，只讲一件事：一个正经写代码的人，在真实工作周里，到底怎么把 Claude 用出去，用在哪儿，以及在哪儿必须刹车。

文中所有数字都来自我们团队内部的粗略统计和估算，样本小、口径不严谨，只当作趋势参考，别拿去当行业基准。

一、先把”怎么用”这件事的三个层次分清楚

很多人对 AI 编码工具的印象还停在”在网页里问一句、复制一段代码回来”。这只是最浅的一层。实际工作中，Claude 在研发流程里的介入方式大致有三种，成本和收益完全不同：

第一层：对话式问答。 你在浏览器或 App 里开一个窗口，粘代码、贴报错、问概念。优点是零成本、零配置，任何人五分钟就能上手；缺点是它对你的项目一无所知，你得手动喂上下文，喂多了嫌烦，喂少了它就开始编。这一层适合做知识性咨询和孤立片段的处理：解释一个陌生的算法、把一段 SQL 翻译成 Pandas、问某个库的 API 该怎么调。

第二层：IDE 内联协作。 通过插件把模型接进编辑器，它能看到你当前打开的文件、光标位置、项目结构。这一层的价值在于上下文自动化——你不用再复制粘贴，它知道你项目里 Portfolio 这个类长什么样，知道你用的是 polars 不是 pandas。补全、重构、局部改写，这些高频小动作在这一层收益最大。

第三层：Agent 模式（Claude Code 一类的终端/桌面 Agent）。 你给它一个目标，它自己读文件、跑命令、改代码、跑测试、看报错、再改。这一层是质变，因为它把”人在循环里逐步指挥”变成了”人在循环外验收结果”。但它也是风险最大的一层：它能改的东西越多，你没看清就合并的概率越大。

我的建议是：三层都用，但按任务性质切换，不要一根筋。 问概念别开 Agent（杀鸡用牛刀，还慢），做跨十几个文件的重构别在聊天窗口里手动贴代码（你会贴到崩溃）。

Anthropic 目前把这几种形态铺得比较全：网页/桌面端的对话、Claude Code（终端、VS Code、JetBrains 都有）、以及面向非开发者的 Cowork。团队里做研究的同学更常用前者，做工程的基本长在 Claude Code 里。

考虑到国内订阅claude确实有点困难，可以参考一下这里：claudemax.shop

二、我这一周的时间去哪了：一个真实的对照

先看一组我们内部统计的数据。我们让团队里 20 个人在引入 Claude 前后各记录了几周的工时明细（自报，有水分，但趋势可信）：

这张图里有三个我觉得值得说的点：

第一，总工时确实降了，但降幅没有网上吹的那么夸张。 从 42 小时降到 33 小时，大约 21%。不是”效率提升 10 倍”，也不是”一个人顶一个团队”。任何声称 AI 让编码效率提升一个数量级的说法，你都可以反问一句：你测的是”敲键盘的速度”还是”从需求到上线的周期”？前者可能真提升几倍，后者能提 20%~30% 就已经很好了——因为软件工程的瓶颈从来不在打字。

第二，”读老代码”这一项从 8 小时掉到 4 小时，是降幅最大的一块。 这一点我后面单独展开，它是我个人认为 Claude 对研发工程师最被低估的价值。

第三，”需求理解与方案设计”和”写测试”两项反而变长了。 这不是坏事，恰恰是我最想让大家注意的地方。当写代码这件事的边际成本降下来之后，你会自然地把时间往上游（想清楚要做什么）和下游（验证做对了没有）挪。AI 不是让你少想，是逼你多想——因为它会飞快地把你没想清楚的东西实现出来，然后你要花更多时间发现”实现得很对，但需求是错的”。

三、按”收益 × 风险”给任务分区

不是所有任务都值得让 AI 参与，也不是所有任务都能承受它出错。我习惯用两个轴来给手头的活分类：它能帮我省多少时间，以及它写错了我要付出多大代价。

右下角绿区：放手交给它

这一片是收益高、翻车成本低的任务，闭着眼睛用：

样板代码与脚手架。 新建一个数据加载器、写一个 CLI 参数解析、搭一个 FastAPI 的路由骨架、配一份 pyproject.toml。这类代码没有智力含量但有记忆负担，你每次都得去翻文档确认参数名。
单元测试生成。 给它一个纯函数，让它把边界条件、空输入、异常路径都覆盖一遍。人写测试最大的问题是懒和想不全，而它不会懒。注意：让它写测试，但测试用例的”期望值”你必须自己核。 常见坑是它把当前实现的行为当成正确行为，写出一堆”实现是什么它就断言什么”的伪测试——这种测试通过率 100%，防护价值为 0。
代码解读与遗留系统考古。 详见下一节。
日志和 Stack Trace 分析。 尤其是 Java 那种几百行的调用栈，或者 C++ 里一坨模板展开后面目全非的报错。它能很快定位到真正的那一行。
SQL / Pandas / Polars 的数据变形。 “我有这样一张宽表，想按标的和交易日做分组，算 20 日滚动波动率，再和另一张表按最近日期做 asof join”——这种描述清楚但写起来啰嗦的活，它一分钟给你，你花两分钟核对一下 join 的方向和 NaN 的处理就行。

中间橙区：让它做草稿，人来定稿

回测框架重构、因子逻辑实现、性能优化。 这些活它做得了，但做得对不对你必须逐行看。特别是因子逻辑，一个符号方向反了、一个 shift 少了一天，回测曲线照样很漂亮，但那是未来函数。
我的做法是：让它先写，我再逐行 review，并且要求它在关键处写注释解释”为什么这么做”。 如果它解释不清楚，多半就是它自己也没想明白，那段代码就要重点怀疑。

左上角红区：自己写，最多让它 review

在金融行业，有些代码你不能交出去：

撮合、清算、风控限额这类核心链路。 不是因为 AI 写不出来，而是因为出错的后果是不可逆的资金损失。这类代码的正确性要靠形式化的、逐行的人工推敲和长期积累的领域直觉来保证。
生产环境的变更脚本。 数据库迁移、批量改仓、灰度切流。这些东西我甚至不建议让 Agent 有执行权限。让它写，人来读，人来跑。
任何涉及敏感数据出域的操作。 后面在合规那节展开。

这个象限图不是给你抄的，是给你自己画的。每个团队、每条业务线的红区都不一样，你应该和团队一起把自己的红区画出来，明确写进工程规范里。

四、最被低估的能力：代码考古

如果只让我留一个使用场景，我会留”读代码”。

金融行业的系统有个特点：活得久，人换得快。 一套跑了八年的风控中台，最初的作者早跳槽了，文档停留在第二版，注释是中文夹拼音，变量名叫 tmp2、flag_new、data_final_v3。而你现在要在里面加一个新的限额维度。

传统做法是：全局搜索、打断点、画调用图、找老员工问，一周过去了你还在拼图。

用 Claude 的做法是这样的（我以 Claude Code 为例）：

# 第一步：先让它建立全局认知，不要一上来就问细节
> 通读 risk_engine/ 目录，画出这个模块的核心数据流：
  从行情/委托进来，到最终产生"拒单"或"放行"，中间经过哪些组件？
  用文字描述，标出每一步涉及的关键文件和函数。

# 第二步：定位你要改的那条路径
> 现在我要新增一个"单标的日内累计成交额上限"的检查。
  在现有架构里，这个检查最应该插在哪一层？为什么？
  列出 2 个候选位置并比较优劣。

# 第三步：让它把隐含约束挖出来（这一步最值钱）
> 在你建议的位置插入检查，有哪些我可能没注意到的坑？
  特别关注：并发访问、状态在多线程/多进程间的共享、
  盘中重启后的状态恢复、以及这段代码是否在热路径上。

第三步是关键。一个陌生系统真正会咬你的，不是”代码在哪”，而是”这里有个约定俗成的规矩，但没人写下来”。 Claude 读了全量代码之后，往往能把这些隐含约束翻出来——比如它会告诉你”这个模块的所有状态都在 RiskContext 里，而 RiskContext 是每个交易日盘前重建的，所以你的累计额如果要跨日就得另找地方存”。

这一条信息，可能就是你和一个 P0 故障之间的距离。

几个实操上的注意：

不要让它一次读太多。 上下文塞太满之后模型的注意力会稀释，宁可分模块问。先建立骨架，再逐层深入。
让它引用具体的文件和行号。 要求它”每个结论后面标出依据来自哪个文件的哪一段”，这样你能快速验证，也能识别它什么时候在编。
给项目写一份 CLAUDE.md。 把项目的技术栈、目录约定、常用命令、绝对不能碰的地方写进去，放在仓库根目录。这份文件是你和 AI 之间的”入职培训手册”，写一次收益长期。我们团队的这份文件里第一条就是：本仓库中 matching/ 和 settlement/ 目录下的任何文件，未经人工确认不得修改。

五、量化研究的完整流水线：一个具体案例

上面讲的偏通用工程。下面讲一个更贴近量化的场景：从一篇论文到一个可入库的因子。

假设需求是：复现一篇讲”日内订单流不平衡（OFI）预测短期收益”的论文，在我们自己的 A 股 tick 数据上验证，产出一份研究报告。

我们把这个任务拆成七步，逐步说 Claude 在每一步的角色：

1. 读论文、拆解因子定义（4h → 2.5h）

把 PDF 丢给它，让它做三件事：

把因子的数学定义抽出来，写成明确的公式和伪代码；
列出论文用的数据频率、样本区间、市场，和我们的数据有哪些不可比之处；
指出论文里没说清楚的地方（这一点特别有用，很多论文对”盘口更新时如何定义 bid/ask 变化”含糊其辞，而这直接决定了因子值）。

节省的时间有限，因为你还是得自己读一遍。但它能帮你从”读懂”直接跳到”能实现”，省掉中间反复回翻的过程。

2. 数据拉取与清洗（6h → 2h）

这是降幅最大的一步。tick 数据的清洗永远是一堆琐碎规则：集合竞价段怎么处理、涨跌停时盘口的异常、停牌日的处理、复权对齐、时间戳精度不一致……

我的做法是把规则写成自然语言清单，让它翻译成代码：

数据清洗规则（请严格按此实现，不要自作主张增删）：
1. 只保留 09:30:00–11:30:00 与 13:00:00–14:57:00 的连续竞价数据
2. 剔除当日曾涨跌停的标的（涨跌停判定：最新价 == 涨停价或跌停价）
3. 时间戳统一到毫秒，按 (symbol, timestamp) 去重，保留最后一条
4. 缺失的盘口档位用 NaN 填充，不要前向填充
5. 输出 schema 必须是：symbol(str), ts(datetime64[ms]),
   bid1..bid5(float64), ask1..ask5(float64), bv1..bv5(int64), av1..av5(int64)

请用 polars 实现，注意数据量约 3 亿行，避免全量 collect 到内存。

关键在最后两句：明确 schema、明确性能约束。不说数据量，它会写出一个在你 200GB 数据上直接 OOM 的实现。

3. 因子计算实现（5h → 2h）

这一步在橙区，属于”它写草稿、你定稿”。唯一必须人工把关的是时间对齐。我的固定检查清单：

计算 t 时刻因子值时，用到的所有数据是否都在 t 时刻之前可得？
滚动窗口的 min_periods 设了没有？没设的话前几个值是用不完整窗口算的，会引入噪声。
标准化/去极值是截面做的还是时序做的？跨截面标准化时，用的是当期数据还是包含未来的全样本统计量？（后者是最经典的未来函数）
因子和收益率的对齐方向：factor[t] 对应的是 ret[t+1] 还是 ret[t]？

我通常会直接把这个清单贴给它，让它自我检查并逐条回答。它答不上来的那条，就是我要重点看的地方。

4. 回测框架对接（3.5h → 1.5h）

如果你有自己的回测框架，把框架的接口文档（或者直接把基类代码）给它，让它按接口写适配层。这是纯粹的机械劳动，收益稳定。

5. 结果分析与可视化（3h → 1h）

IC 序列、分组收益、换手率、分年度表现、不同市值分组下的稳定性……这些图每次都要画，每次都要调格式。让它一次生成全套，你只管看结论。

这里有个技巧：把你团队的绘图规范固化成一个模板文件，让它每次都基于模板改，输出风格才能统一。

6. 写研究报告（4h → 1h）

把回测输出的数字和图丢给它，让它按你们的报告模板写初稿。但结论段必须你自己写。 因为它会倾向于说好话——你给它一组 IC 均值 0.03 的数据，它能写出”该因子展现出稳定的预测能力”。而实际上你得看 IC 的 t 值、看衰减、看剔除掉小市值之后还剩多少。AI 不会替你承担研究结论的责任。

7. 代码 Review 与合并（1.5h → 1.8h）

注意这一步变长了。 这是整张图里最重要的信息：AI 产出越多，人的把关成本越高。

如果你的团队引入 AI 之后 review 时间没变，只有两种可能：要么你们没真在用，要么你们在把没看懂的代码往主干上合。第二种情况的账，迟早要还。

六、团队层面会发生什么：有个阵痛期

个人用和团队用是两回事。下面是我们一个 20 人研发团队接入之后 6 个月的三条曲线：

第 1 到第 3 个月是明显的阵痛期。 代码产出量上去了，但 Code Review 打回率从 8% 飙到 26%，线上缺陷密度指数一度涨到 121（相对 M0 的 100）。原因不难理解：

大家一开始不知道边界在哪，什么都想让 AI 干，包括不该干的；
Review 的方式没跟上。以前 review 是”看这个人的思路对不对”，现在变成”看这段来路不明的代码有没有坑”，认知负担完全不同；
代码风格开始漂移，同一个仓库里出现三种不同的错误处理模式，因为不同的人用不同的提示词生成。

第 4 个月之后曲线开始回落，我们做了几件事：

写工程规范，明确红区（见第三节），并在 CLAUDE.md 里固化项目约定；
在 PR 模板里加一栏：本 PR 中 AI 生成的部分占比大约多少，你逐行看过了吗？这一栏不用来考核，只用来提醒；
把 review 的重点从”风格”转向”逻辑与边界”，风格交给 linter 和格式化工具，人只看那些机器看不出来的东西；
要求关键模块的测试必须人工写，至少断言部分必须人工写。

到第 6 个月，采纳率稳定在 80% 左右，打回率降到 12%（略高于起点，我认为这是合理的新常态），缺陷密度反而比引入前低了 17%——主要贡献来自测试覆盖率的提升。

这条曲线的形状比绝对数值更值得记住：先降后升，中间有个坑。 如果你是团队负责人，要提前给管理层打预防针，别在第二个月看到缺陷上升就急着把工具下掉。

七、金融行业绕不开的合规问题

这一节可能是本文对同行最实际的部分。在券商、基金、银行这类持牌机构里，用任何外部 AI 工具都要先过合规这关。几个必须想清楚的点：

1. 数据出域。 客户信息、持仓、委托流水、未公开的策略参数——这些东西不能进任何外部服务的请求体。这不是”最好不要”，是硬红线。实操上：

贴代码时把常量、配置、连接串全部替换成占位符；
描述数据结构时用 schema 而不是样本数据；
涉及真实数据的调试，用脱敏后的合成数据复现问题。

2. 部署形态。 如果机构有私有化或 VPC 内部署的条件（走云厂商的托管服务、或者企业版的数据保留政策），优先走那条路。不同产品形态的数据处理条款差别很大，这个必须让法务和合规同事去逐条看，不要靠工程师拍脑袋。

3. 代码知识产权与开源合规。 生成的代码是否可能与某个 GPL 项目高度相似？这在监管审计里是会被问到的。我们的做法是：核心模块保留完整的人工作者记录，并对生成代码做一次开源相似度扫描。

4. 可解释与可审计。 风控和投研的模型逻辑要能对监管解释清楚。如果一段风控代码的实现逻辑连写它的人都说不明白（因为是 AI 写的、他只是跑通了），那就是审计事故。“我能对着监管逐行解释这段代码”应该是合并到主干的前置条件。

八、几个提升效果的具体手法

讲完场景，说几个我自己觉得回报率很高的小技巧。

1. 用”约束清单”代替”需求描述”

差的提示词：“帮我写个函数计算夏普比率” 好的提示词：

写一个计算年化夏普比率的函数。

输入：pd.Series，索引为交易日 DatetimeIndex，值为日频简单收益率
参数：rf 年化无风险利率（默认 0.02），periods_per_year（默认 252）
要求：
- 无风险利率要先折算到日频再扣减，不要直接用年化值减
- 收益率序列长度 < 20 时返回 np.nan 而不是报错
- 标准差用 ddof=1
- 不要静默丢弃 NaN，遇到 NaN 抛 ValueError 并提示位置
- 加 type hints 和 numpydoc 格式的 docstring

区别在于：第二种把你脑子里的隐含标准显式化了。 你不写，它就按最常见的写法来，而”最常见的写法”在金融计算里往往是错的（比如年化无风险利率直接减，这个错我在生产代码里见过不止一次）。

2. 让它先给方案，再写代码

对稍微复杂一点的任务，加一句：“先不要写代码，给我两到三个实现思路，比较各自的取舍，我选定之后你再实现。”

这一步能挡掉大部分返工。因为一旦它开始写代码，你的注意力就会被具体实现吸走，很难再退回来质疑方向。

3. 让它扮演审稿人

写完自己的代码之后，把代码丢回去：

你是一个严格的 code reviewer，专门审量化研究代码。
请找出这段代码中所有可能导致未来函数、幸存者偏差、
或前视偏差的问题。如果没有问题，明确说没有，
不要为了凑数编造问题。

最后那句很重要。不加的话它会硬找问题，给你一堆无关痛痒的”建议增加异常处理”。

4. 会话卫生：该开新窗口就开新窗口

一个会话越长，前面的错误假设越容易被继承下去。当你发现它开始反复犯同一个错、或者忘记了你早先定的约束时，别在原会话里继续纠正，直接开新的，把必要上下文重新组织一遍贴进去。 重新组织上下文的这个动作，本身也会帮你理清思路。

5. 建立你自己的提示词库

那些你每周都要用的东西——数据清洗规范、因子检查清单、报告模板、review 检查项——固化成文件，需要时直接引用。这是复利最明显的一件事。

九、对不同阶段工程师的建议

如果你是应届/初级： 最大的风险不是不会用，是用得太顺以至于跳过了理解。你现在正处在积累”代码直觉”的阶段，这个直觉只能靠自己踩坑长出来。我的建议是：允许用 AI 帮你查资料、解释代码、写样板，但核心逻辑坚持自己写完再让它 review。你需要的是它当老师，不是当枪手。

如果你是中级： 你的杠杆最大。你已经有判断力，能看出它什么时候在胡说，同时手上又有大量重复性劳动可以外包。把精力放在建立个人工作流上：配好 Agent、写好 CLAUDE.md、攒好提示词库。这一年能拉开的差距，主要在这一层。

如果你是资深/带团队： 你的重点应该从”我怎么用”转到”团队怎么用”。写规范、划红区、改 review 流程、准备好应对第 2-3 个月的指标下滑。另外，认真想一想：当写代码的成本降下来之后，你们团队真正的瓶颈是不是已经转移了？ 我的观察是，大多数团队的瓶颈很快就会从”实现速度”变成”需求质量”和”验证能力”，而这两件事目前还没有便宜的外包方案。