8 篇博文 含有标签「software-engineering」

这种规律在 2023 年和 2024 年采用编程智能体的团队中几乎普遍存在。第一个月，效率翻倍。第三个月，管理层把生产力指标拿出来，作为 AI 投资回报的证据。到了第十二个月，工程团队有一半的代码库已无法向新员工解释清楚，重构成本高得令人望而却步，工程师花在调试 AI 生成代码上的时间，比他们手写这些代码所需的时间还要多。

这不是一个关于 AI 代码暗中存在缺陷的故事。这是一个关于 AI 生成代码的质量特征如何系统性地瓦解团队已有的组织实践的故事——以及这些实践在技术债务复利失控之前需要如何改变。

每个曾将模块委托给外包的工程师都知道那种感觉：代码交回来了，测试通过了，演示也能跑——但你完全不知道它到底好不好。你没有写它，你不完全理解其中蕴含的决策，而你即将进行的审查更像是走过场而非真正的实践。现在把这种动态乘以你代码库中每一个AI辅助的提交。

AI委托悖论很容易表述，却很难逃脱：你最需要用来评估AI生成工作的技能，恰恰是你停止亲自动手后退化最快的技能。这不是未来的风险，而是正在发生的事实，在那些拥抱AI编码工具的工程组织中已经可以量化测量。

每个工程组织都有这样的人。他们不拥有产品，不交付用户可见的功能。但没有他们，一切都无法运转。他们是编写 ETL 管道、将数据从计费系统搬到分析仓库的工程师；是构建 Webhook 处理器、让 Salesforce 与内部 CRM 保持同步的人；是维护 API 适配层、让移动端应用能与三个从未被设计为相互通信的后端服务对话的人。

他们就是胶水工程师，而他们的工作是第一批被 AI 代理完全吞噬的软件工程类别。

你的智能体 v1 能用。它很丑，靠提示词胶带勉强维持，每次打开代码都让你皱眉。但它能处理 90% 的情况，用户很满意，每天都在创造价值。于是你自然而然地决定：从头重写。

六个月后，重写版本仍未上线。你迁移了两次框架，为一个根本不需要的问题搭建了多智能体编排层，评估套件测试的全是那些从不出错的地方，真正容易崩溃的地方一个没测。与此同时，v1 依然在跑——依然很丑，依然好用。

这就是第二系统效应，它在我们大多数人出生之前就已经摧毁了无数软件项目。

大多数运行 AI 编程智能体（AI coding agents）的团队都在优化错误的变量。他们过度痴迷于模型选择 —— Claude vs. GPT vs. Gemini —— 却将周围的脚手架视为次要的配套工作。但基准测试数据和生产环境的实战经验告诉我们一个不同的故事：一个在演示中令人惊叹的模型与一个能够可靠交付生产代码的模型之间的差距，几乎完全取决于其周围的控制环（harness），而不是模型本身。

这个公式看似简单：智能体 = 模型 + 控制环 (Harness)。控制环是除此之外的一切 —— 工具 schema、权限模型、上下文生命周期管理、反馈循环、沙箱环境、文档基础设施、架构不变性。如果控制环搞错了，即使是最前沿的模型也会生成虚构的文件路径，在会话进行到 20 轮时破坏自身的约定，甚至在没写任何测试之前就宣称功能已完成。

对于习惯于编码、构建和自动化的软件工程师来说，涉足量化交易是一个充满吸引力的领域。然而，第一个挑战便是选择合适的工具。你应该选择像 TradingView 这样整合良好、开箱即用的平台，还是投入 Python 生态系统的怀抱，享受其无穷的灵活性？

本文将从软件工程师的视角，深入剖析这两种主流方案的优劣，帮助你找到最适合自己的交易武器库。

🚀 TradingView & Pine Script：一站式的快速原型平台​

TradingView 以其流畅的图表和庞大的社区而闻名。其内置的 Pine Script 是一种专为交易策略开发设计的领域特定语言 (DSL)。

核心优势：​

• 极低的入门门槛：Pine Script 语法简洁，专为时间序列操作优化。你可以用 ta.sma(close, 14) 这样简单的代码，快速实现复杂的技术指标。
• 即时可视化：最大的亮点在于其无缝整合。代码在左侧的 Pine 编辑器中编写，点击“添加到图表”，策略信号和指标立即呈现在右侧的交互式图表上。这种“所见即所得”的工作流程，极大地加速了策略的开发和验证。
• 强大的社区生态：拥有超过 15 万个由社区贡献的公开指标和策略脚本。无论你需要什么，很可能已经有人写好了。这是一个学习和寻找灵感的金矿。
• 内置回测与警报：只需将脚本声明为 strategy()，即可使用内置的策略测试器进行回测，并获得详细的绩效报告（净利、回撤、胜率等）。其强大的警报系统可以通过 Webhook 将交易信号发送到任何指定的 URL，为半自动化交易铺平了道路。

主要限制：​

• 有限的扩展性：Pine Script 是一个沙盒环境。你无法导入外部 Python 函数库、读取本地文件或进行网络请求。这意味着整合机器学习模型、另类数据或自定义分析变得几乎不可能。
• 无原生自动交易：这是最关键的一点。TradingView 本身不支持将策略信号自动发送到你的券商账户执行。尽管可以通过警报 (Alerts) + Webhook 的方式间接实现，但这需要你额外设置一个中间服务来接收信号并调用券商 API。

洞见：TradingView 是量化交易的绝佳入口。它专为可视化和快速迭代而生，非常适合用来验证基于技术分析的交易点子。它就像一个功能强大的 IDE，但专为交易图表而设计。

🐍 Python 生态系统 (Backtrader & Qlib)：打造专属的交易宇宙​

对于追求极致控制权和灵活性的工程师来说，Python 生态系统是必然的选择。以 Backtrader 和 Qlib 为代表的开源框架，让你能从零开始打造完全定制化的交易系统。

核心优势：​

• 无限的灵活性：你可以整合 Python 生态中的任何工具，例如用 Pandas 处理数据、用 NumPy 进行高速运算、用 Scikit-learn 或 PyTorch 训练机器学习模型来产生交易信号。
• 完全控制数据源：你可以加载任何来源的数据，无论是 CSV 文件、数据库，还是各种另类数据 API。这对于测试非传统策略至关重要。
• 精细化的回测与实盘交易：
  • Backtrader 是一个成熟的事件驱动回测框架，支持多资产、多时间周期的投资组合级别回测，并且可以直接对接盈透证券 (IB) 等券商进行全自动实盘交易。
  • Qlib 是由微软开源的 AI 量化投资平台，专注于端到端的量化研究流程，从数据处理、特征工程到模型训练和组合管理，特别适合进行复杂的 AI/ML 策略研发。
• 开源与免费：这些框架完全免费且开源，你可以根据需求修改其核心引擎，没有任何平台限制。

主要挑战：​

• 陡峭的学习曲线：你需要自己处理所有事情：数据获取与清洗、指标计算、回测引擎设置、绩效可视化以及实盘交易的基础设施。这一切都需要投入大量的时间和精力。
• “重复造轮子”：TradingView 上一键添加的图表和绩效报告，在 Python 中可能需要你编写数十行 matplotlib 或 Plotly 代码才能实现。

洞见：Python 赋予你无上的权力，但也要求你承担全部的责任。它适合那些目标明确、需要高度定制化、并且不满足于单纯技术指标分析的严肃交易者和量化研究员。

📊 如何抉择：一条清晰的路径​

那么，你该如何选择？答案取决于你的当前目标和技术深度。

1. 新手探索阶段 → 从 TradingView 开始​

如果你是首次涉足量化交易，或者只是想快速验证一些交易点子： 首选 TradingView。它的即时反馈和可视化特性无可匹敌。你可以专注于策略逻辑本身，而不用分心于基础设施的搭建。在这里，你可以快速学习什么是有效的，什么是无效的。

2. 寻求自动化与定制化 → 转向 Python​

当你发现以下情况时，就该考虑 Python 了：

• 你的策略需要整合外部数据或机器学习模型。
• 你希望实现全自动化的实盘交易，而不是依赖手动或半自动的 Webhook。
• 你需要进行复杂的投资组合级别回测，而不只是单一资产。
• TradingView 的平台限制（如历史数据长度、警报数量）成为了你的瓶颈。

3. 两全其美 → 混合模式 (Hybrid Approach)​

这是一个在社区中非常流行且高效的工作流程：

• 使用 TradingView 进行研究和原型设计：利用其出色的图表工具和庞大的社区脚本库，快速开发和验证策略。
• 使用 Python 执行交易：一旦策略在 TradingView 上被证明有效，就将其逻辑用 Python 实现。然后，利用 TradingView 的警报 Webhook 功能将信号发送到你用 Python 搭建的、连接到券商 API 的执行服务器上。

这种方式结合了 TradingView 的开发效率和 Python 的执行能力，让你两边的优点都能享受到。

结论​

TradingView 和 Python 并非是相互排斥的对手，而是在量化交易旅程中处于不同阶段的工具。

• TradingView 是一个整合了数据、图表、开发和社区的一站式平台，是完美的起点和强大的分析工具。
• Python 则是一个赋予你无限可能性的强大生态系统，是打造专业、复杂交易系统的基石。

作为软件工程师，最好的策略是理解两者的核心权衡：便利性 vs. 灵活性。从 TradingView 开始，当你的需求超出其能力范围时，再自信地投入 Python 的怀抱，甚至可以结合两者，打造出属于你自己的最佳交易系统。

20% 时间​

工程师被允许花费他们 20% 的工作时间给任何一个他们自己想要贡献的项目，不用寻求他们经理或者其他人的同意。这非常有价值，因为：

1. 只要有好的想法，甭管一开始听起来有多烂，都有充足的时间去实现它到一个可以 demo 的状态。
2. 给管理者看到他们原本看不到的活动，否则工程师会搞“skunkwork” 偷偷干活。
3. 允许工程师干一些有趣的东西，防止他们 burn out，激励他们让他们更开心。有干劲的工程师和 burnt-out 的工程师在产出的差距是远超 20% 的。
4. 鼓励创新，如果周围其他人都做 20% 项目，你也会受到感染去做。

OKRs​

个人和团队都必须公开记录他们的目标和对目标的衡量。

• Objectives 目标
  • 设置季度和年度的目标
  • 个人和小组的目标要和大组的目标看齐 （align ）
• Key Results 关键结果: 通过可测量的关键结果，可以算出达到目标的进度，范围是从 0 到 1。
• OKR 尽量往高里设，最后一般达到 0.65 是一个不错的标准，如果你的执行结果常常低于它说明目标设置得太高，高于它说明目标设置得太低。
• 好处
  • 大家互相知道在干什么，能够互相激励
  • 让执行有了目标，让目标更容易被执行
• ORKs 与绩效考核不是直接相关的

项目继续做还是终止？​

尽管对于重大的新发布的审查是流程化的，但是某个项目该不该做这种问题却没有定论，有些是自下而上的决定，有些是自上而下的决定。

重组 (re-org)​

组的分拆以及合并是家常便饭，似乎这样做能够优化效率。

我的评价​

20% 时间的结果是好的，比如孵化了 Gmail，AdSense 等等举足轻重的项目。在一个跑马圈地的年代，鼓励优秀的工程师花一些时间做一些新东西是非常合算的。在公司还小需要用非常好的福利措施来吸引人才的时候，宣扬 20% 时间也是一种特立独行的手段。我更倾向于 20% 时间是一种管理风格，而不是成功的必然原因。

ORKs 与绩效考核不直接相关，这种区分非常重要 —— 换句话说，就是愿景与执行分离，目标管理与绩效管理分离。举个例子，你开车从 A 点到 B 点，“你有没有到终点？”，对比，“你开的这辆车是不是好车？”，其实是两个不同的问题。同样的道理，产品最后卖的不好，与工程师有没有做出好的产品，是两件不同的事情。

对于普通的工程师来讲，在大公司里面跟其他组，包括跟你具体工作没关系的其他组，保持好的关系很重要，因为这相当于你在劳动力供求的市场上多出了一些需求方。这样一旦发生重组或者其他不利的事件的时候，你能够有更多的选择。

业界公认，谷歌是一家工程能力超强的公司。它有哪些好的工程实践？我们可以在里面得到哪些启发？其中又有哪些地方是被人诟病的？这些内容比较细致我们慢慢讲，本篇主要是讲开发。

代码库​

• 截止15年有 20 亿行代码存在少量的 Monorepo 单一代码库中，绝大部分代码对所有人是可见的。谷歌鼓励工程师见到有问题就可以改，只要所有人审核通过，就能进库。
• 几乎所有的开发都是在代码库的头部 (head) 进行的，而不是在分枝上，避免 merge 时候遇到问题，安全修复也更方便。
• 每个改动都会触发测试，有错几分钟内就能通知作者和审查者。
• 代码库的每个子树至少有两个所有人，其他开发者可以提交修改，但是所有人批准才能进库。

构建系统​

• 分布式构建系统 Bazel 让编译、链接、测试轻松快速。
• 成百上千台机器。
• 可靠性高，确定的依赖输入导致确定的结果输出，不会出现奇怪的不确定的抖动。
• 快。一个构建结果缓存了，依赖它的构建会直接采用缓存，不必重新勾结。只会重新构建改动的部分。
• 提交前自检 (pre-submit checks)。一些快速的测试可以在提交前先执行。

代码审查​

• 有代码审查工具
• 所有改动必须有审查
• 发现 bug 之后可以去之前的那个审查上指出问题，相关人员会被邮件通知到
• 实验性质的代码不用强制审查，但是生产环境下的代码一定会被审查
• 鼓励每个改动尽量小。百行以内是“小”，三百行以内是“中”，一千行以内是“大”，超过一千行是“超tm大”。

测试​

• 单元测试
• 集成测试、回归测试
• 提交前检查
• 自动生成测试覆盖率
• 部署之前做压力测试，并产生相应的关键指标，尤其是延迟、错误率随着负载的变化

Bug 追踪工具​

Bugs, feature requests, customer issues, process 等等都记录起来，需要时常 triage 以确认优先级然后分配给相应的工程师。

编程语言​

• 限制有五个官方语言 C++, Java, Python, Go, JavaScript，以便代码重用和开发协作。每种语言有风格指南。
• 工程师要经历代码可读性培训。
• 当然某些场合的 DSL (Domain-specific language) 也不可避免。
• 这些语言之间的数据交互主要是通过 protocol buffers。
• 通用流程很重要，不同的语言，同样的工作流程

Debug 和分析工具​

• 服务器崩溃时，崩溃信息会自动记录下来。
• 内存泄漏会附带上当前的 heap 对象。
• 有大量的 web 工具帮你检测 RPC 的请求、改变设置、资源消耗等等。

发布​

• 大多数的发布工作是普通的工程师自己做的
• 及时发布很重要，因为快速的发布节奏能够极大地激励工程师多干活、更快地得到反馈
• 典型的发布过程：
  1. 找最新的稳定 build ，做一个 release branch，可能再附带 cherry-pick 一些小改动
  2. 跑测试与构建、打包
  3. 发布到 staging 服务器上内部测试，这时候可以 shadow 一下线上的流量，看看有没有问题
  4. 发布到 canary 上承接少量的流量公开测试
  5. 逐渐发布给所有的用户

对发布的审查​

用户可见的、或者是重大的发布必须有相关的法务、隐私、安全、可靠性、业务需求相关的审查批准，确保相关人员被通知到。有专门的工具来辅助这个流程。

尸检报告​

有重大的 outage 事故发生之后，相关责任人必须写尸检报告，内容包括

1. 事件标题
2. 总结
3. 影响：发生了多久、影响了多少流量、损害了多少利润
4. 时间轴：记录时间的发生、诊断和消弭
5. root causes
6. 做的好的地方，做的不好的地方：有什么经验能够帮助他人在下一次更快更准地找到并解决问题？
7. 接下来的可行动作：有什么接下来可以做的事情能够避免将来类似的事情发生？

对事不对人，这里的关键是理解问题本身、以及将来如何避免类似问题。

重写代码​

大量的软件每隔几年就会被重写一次。坏处是确实成本高，好处是

1. 保持敏捷。市场在变，软件的需求也一直在变，代码也需要随之变化以应对不时之需。
2. 降低复杂度。
3. 传承知识给新人，让他们有拥有感。
4. 提高工程师的移动性，促进跨领域创新。
5. 采用最新的技术栈和方法论。

我的评论​

谷歌的单一代码库和强大的构建系统是小公司不可学的，毕竟小公司没有资源和能力让构建系统快到敏捷可用；保持小、简单、快速会让小公司跑得更顺畅，更加专注于核心业务逻辑。

构建系统通常是定制化的，你的知识无法迁移和衍生。强大的构建系统对新手甚至是有害的，因为提高了新手俯瞰全局的成本。

知识无法迁移和衍生也是完善的内部工具 (in-house tools) 的问题。我在职业生涯中会尽量避免使用不会开源的内部工具，比如 Uber 的 Schemaless，只针对特定的场景且没打开放出来算做大做强 ；而相反的， Linkedin 的 Kafka 则是一个有开放性和衍生性的知识的好产品。

在公开市场，这整个开发、测试、集成、发布的流程都有非常好的工具帮你来做，举个 JS 社区的例子：

流程	工具
代码库	Github, Gitlab, Bitbucket, gitolite
代码审查	Github Pull Requests, Phabricator
提交前自检、测试与 Lint	husky, ava, istanbul, eslint, prettier
Bug Tracking	Github Issues, Phabricator
测试与持续集成	CircleCI, TravisCI, TeamCity
部署	发布在线服务的 Heroku, Netifly, 发布移动 App 的 Fastlane, 发布库的 NPM

最后，我可能有一个洞见，不注重这些工程流程自动化的细节的公司，在工程上会损失巨大的竞争力。我甚至为了良好的工程实践自己配了一个 JS 全栈开发框架 OneFx。快节奏与慢节奏、高质量与低质量差别，通常是指数级别的，因为 —— 通常，快会让你更快更多，差会让你更差更少。