TL;DR

AI辅助研发已经走过Chat、Copilot，进入Agent时代，为了让Agent更大程度地帮助人们提效，AI生成的产物，要直接成为研发流程中的交付件，并且要易于编辑审核。SDD将海量，人难以review的代码抽象成了更易编辑审核的SPEC，但目前业内大多数 SDD 实践，还主要停留在“代码生成”阶段。而在真实企业研发中，代码只占整个研发活动的一小部分。漏洞处理、现网事件、上线说明、影响评估…….未来整个流程逐渐演化为Agent输出可结构化、可审核的交付件，人仅审核的方向发展，最终”SDD会吞噬一切”。

为什么会有SDD，SDD是什么？

现在是2026年，距离GPT4发布已经过去了3年，AI辅助研发，经历了很大的改变，从Chat、Copilot再到Agent。现在没有用过Agent模式辅助开发的人，恐怕你已经有一些落后了。

Agent模式下，AI生成代码的速度越来越快，以原先的方式提交、检视代码，甚至合并冲突都非常耗时，这种模式下，人越来越没有能力掌控代码。

这是我在开发一个个人业余项目时跟Codex对话过的原话：

我在“如何让AI真正替你干活“中提到过提效的关键取决于”AI生成的产物，是否是最终的交付件，是否易于编辑。 代码本身是易于编辑的，所以它成为了AI率先提效的对象，但量变引起质变，海量的代码已经不再易于编辑和审核。

为此，人们在已有的软件工程下，追求新的抽象层次，代码不好维护，那我想办法维护别的不就好了？

这就是SDD的核心理念，SDD通过结构化的规格文档（Spec）作为可信生成源，让 AI 围绕规格进行实现，而人类主要审核规格本身，而不是陷入海量代码细节。这些规格通常以 Markdown 等易读、易维护的形式存在，例如 Spec.md、design.md、tasks.md 等。

这就好像，我生成一个短剧视频，比如一次生成了2min，我想修改里面的部分很难，但是如果我先用AI生成首尾帧图，每次生成5秒钟，我先调整首尾帧图，再生成一样。

不过从目前的实践来看，SDD还没能那么理想地屏蔽掉代码层，一些小修改，例如配置、端口、脚本、热修复，我们仍然会直接修改代码文件，而不会重新回到 Spec。

但无论如何，SDD已经算是目前较为优秀的一种实践。这同时也让我们理解了要让AI生成的产物，就是最终的交付件，要易于编辑。

企业级研发全流程提效的下一个阶段

目前业内主流的SDD的实践，比如OpenSpec，主要聚焦于代码生成流程：

但是在企业级研发中，真实的研发活动是一个由大量角色、流程、交付件组成的网状协同系统，单纯的写代码，只占真实研发活动中的很小一部分，比如还有 友商的洞察、漏洞检测报告漏洞处理。

那么这些步骤，其实像OpenSpec这样的工具还是帮不上忙的，我们举几个例子：

场景一：漏洞报告处理

企业今天可以通过扫描平台、运行时检测等工具，自动发现大量漏洞。但真正耗时的，其实并不是修改漏洞代码本身，而是整个处理流程：

代码修改只是其中的很小一个部分，还有很多阶段还没有让Agent介入，可能还只是在用”Chat”模式提效。接下来通过开发Agent，由Agent分析漏洞影响输出交付件，人确认，Agent基于漏洞处理的特点（修改尽量不要太大等等）给出修改意见，人确认，自然而然地达成全流程AI提效。

场景二：SDD、TDD融合

Agent把个人的能力放的这么大，我有时也跟朋友闲聊到，将来一个小的公司，老板不太懂的情况下，三个技术人员就够了，又有容灾能力，又能讨论决策出结果。

然而大企业却绝不可能只招聘数个技术人员，这就意味着没法尽量让一个人负责工作的各个方面，有些研发流程就很适合像”首尾帧”那样拆解。

过去很多团队推行 TDD（Test-Driven Development），开发人员不是先写代码，而是先写 测试用例、输入输出，然后再让代码去满足这些约束。

有些很极端的例子，比如
func sum(x, y) {
return 42;
}
先让40+2的用例通过。

某种程度上来说，TDD其实已经具备了一部分 SDD 的思想 不再直接围绕代码本身开发，而是围绕“可验证的约束”进行开发。 但是在过去这个成本非常高。现在充分利用Agent的能力，我们甚至可以做得比Agent直接生成代码更快更稳。

最终，这个流程的每一个红色箭头，都可以使用Agent快速提交，并且每一步都有可审核、可编辑的交付件，希望不会再出现文章开头的问题(笑)。

总结

我们在这里还只展开了两个流程，真正企业里的研发流程只会更加复杂，我让AI生成了一张图：

最终，随着Agent产出效率越来越高，整个研发流程都需要尽量使用Agent提效，这些原本依赖大量人力协同的研发交付流程，最终都会演化为”Agent生成交付件，人类负责最终审核与治理”。而整个企业研发体系，都会围绕这些交付件重新组织，最终SDD会吞噬一切。

我写这篇文章来抒发一些想法，另一方面是作为我之前一篇文章的后续。此刻，我又想起来聂帅给我讲过的”人的思维是螺旋上升的”。

我们还是以开发者测试举例，因为之前提了很多想法，虽然我的角色有些变化，大家还是在找我讨论，谢谢大家看得起我（笑）。

为了满足读者的背景，我来给大家快速补齐一下角色和平台：

• 测试：把握整体，确保测试的分层，避免大量都是耗时的集成测试用例，结合我们的资源、我们的开发测试比例，将部分确定性，执行相对更简单的测试放到开发者侧。
• 开发：按照测试的总体设计书写用例，这有很多种方式，比如就写在代码的test里、用低码平台书写，但核心你一定要和测试平台关联，这个关联有很多方式，低码平台那自然是天生关联的，写在本地代码里的话呢？有很多方式，我最推荐的是用测试平台的id（这可能有意义，也可能无意义），Anyway，再把测试平台的描述（这很让人难看懂）放到测试方法的注释里。这样我们测试就只有一个Truth，就是测试平台，从工程上会更好。当前为了炫技，我还考虑过用Powershell解析Java语法生成，还买了一本Powershell的书（笑），需要投入太大，后来就没搞了。
  
• 某低码平台：没什么的好说的
• Test平台：基本上上面都讲了

2024年，我倾向于在代码仓书写测试用例的方式来完成API Test的工作，它实际会更快一点。
2025年到不久之前，我在想低码化是不是更好，代码将来是burden，是负担。人来仅维护描述，测试用例的书写相对很模块化。

但是，最近我们将 测试平台的id（这可能有意义，也可能无意义），Anyway，再把测试平台的描述（这很让人难看懂）放到测试方法的注释里 这一部分SKILL化了，这是很大的提升，过去，我们对着测试平台一个一个复制方法名称，再把描述拷贝到注释里，这样的工作不复存在了。SKILL起码把这一细分流程的效率提升了10倍以上。可以预想，开发者不会再抗拒这个工作，为什么要拒绝有丰富经验的测试帮你设计好的用例呢，同时还生成了方法名、注释来引导Agent更好地生成代码。

这某种程度上也是贯彻SDD的理念，将流程串起来了。

最后是我想抒发的感受，过去，我们开发一个这样的工具，可能需要一周以上的时间不止，现在我们用SKILL，优秀的工程师们，一天乃至半天的时间就可以完成。尝试让AI Agent直接生成交付件，把重复的工作SKILL化。

AI已经极大程度地更改、影响了这个世界的走向，我们可以看到一些趋势，比如 画师、网文写手、真人短剧逐渐地被替代，程序员的替代还没有那么快。

大家有没有想过这个原因呢？我认为核心就在于：AI生成的产物，是否是最终的交付件。

这和Leader分配任务给下属一样，如果下属的交付件可以直接用，那Leader可能就说，你这个代码日志一定要符合规范、你这个材料字号要调大一些；反之，可能Leader就用下属的没那么完美的交付件，自己再整理成最终的交付件。

而程序员的情况不同：代码不是最终交付件，系统才是。

代码只是中间产物，它需要：运行、集成、部署、监控、演进。这一整条链路还没有完全“标准化交付”，所以替代速度较慢。

那么结论其实很自然，个人提效的关键就在：让AI Agent直接生成交付件，这个交付件一定要是可通过迭代提示词、上下文不断优化的，最好这个产物是可编辑的（Markdown、Excel、Html），最后一公里的时候人可以做一定的修改。我在2月27日的朋友圈里也表达了类似的观点。

那么怎么更好地让AI Agent生成工作中用的交付件呢，我目前的实践是 Agent+MCP+SKILLS+PARA。Agent 负责执行，MCP 连接外部世界，SKILLS 提供可复用能力，PARA 提供稳定上下文，我们一个一个解释。

Agent+MCP

Agent毋庸多说，相比于只能对话的LLM，是一个围绕目标，能够多步执行、调用工具并持续迭代的执行单元。Ask模式（只跟AI对话）是没法更进一步地提效的。

SKILLS

SKILLS可以理解为一组可复用的能力模板（Prompt + Tool + Workflow 的组合）。例如

• 整理Inbox文件
• 生成周报
• 分析某个Area的内容
• 输出某种固定格式的文档
  如果没有SKILLS，每一次都在“重新提示AI”，有了SKILLS，相当于把最佳实践固化下来，交给Agent反复使用。

PARA

对于Agent来说，与其给 AI 造新工具，不如给它一个它已经「会用」的旧接口。在于 LLM 的训练数据。LLM在训练阶段已经看过了很多文件系统的操作，grep、ls、find等等。LLM会非常善于在文件系统里探索他想用的内容，而不是拼凑一个高度定义的DSL。

PARA呢，和文件系统强强联合，给Agent提供了一个稳定、可理解的上下文环境。

个人实践案例

我的PARA目录

PARA是一个指导原则，每个人的PARA都可以有一些定义，比如我的PARA目录是这样子的，适配了我平时使用的OneDrive(它会强制有一些顶层文件夹，我自认为巧妙地利用起来了)，同时我还有把一些作为Blogs发布的诉求。同时也放了一些README.md、About.md 方便Agent读取。

如果大家感兴趣的话，我可以单独写一个文章介绍一下。

1
2
3
4
5
6
7
8
9
10
11

生活/
Archive/
Areas/
Attachments/
Blog/
Documents/
Projects/
Resources/
Software/
About.md
README.md

下面的实践过程，本质上不是一次性的。

如果你每隔一段时间都需要做类似的事情，比如：

• 盘点近期工作成果
• 挑选可以对外分享的主题
• 判断哪些材料已经足够支撑一次输出

那么这个流程其实是高度稳定的：

1. 扫描目录
2. 识别活跃内容
3. 提取关键材料
4. 组织成候选结果

这类流程，就可以被固化为一个 SKILL，例如

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Skill: summarize-workspace-for-sharing

输入：
- 一个工作目录路径

输出：
- 可用于分享的主题列表
- 每个主题对应的支撑材料
- 是否已经具备“可交付”的判断

内部流程：
- 扫描最近活跃文件
- 聚类主题
- 评估材料完整度

这样一来，下次再做同样的事情，就不需要重新写 Prompt，而是直接调用这个 Skill。

实践1：筛选个人成果用于会议分享

向 Agent 提问

1

这是我的个人工作文件夹，你可以看看我最近几个月的工作成果，看看有没有什么东西可以拿去"ApacheCon"分享的？

Agent 回复

1
2
3
4
5

我会先快速梳理这个工作区最近几个月的文件分布和活跃项目，找出适合做 ApacheCon 分享的候选主题，再回头看哪些材料已经足够支撑成一场 talk。

已探索 3 个列表，ran 1 command

我已经看到这个目录更像一个长期知识库，不只是单一项目，所以接下来我会缩小范围：重点看近 6 个月新增或活跃的 Apache / 开源 / AI研发 相关材料。

实践2：整理 Inbox，迁移到合适的 PARA 目录

个人文件夹里最容易失控的地方，通常不是 Projects，也不是 Resources，而是各种临时下载、微信传文件、会议附件、截图和草稿。它们会先堆在一个“待处理区域”里，时间久了以后，人自己都不太愿意翻。

这种场景其实很适合交给 Agent。因为它不需要一开始就“理解整个世界”，只需要先做一件很具体的事情：识别这些文件分别属于什么类型，应该进入哪个目录。

向 Agent 提问

1

这是我的 Inbox 目录，里面有很多最近积累的文件。你可以帮我分析一下这些文件分别属于 Projects、Areas、Resources 还是 Archive 吗？先不要直接移动，先给我一个整理建议和理由。

Agent 回复

1
2
3
4
5

我会先扫描 Inbox 里的文件名、扩展名、最近修改时间，以及部分文档内容，判断这些文件更像是项目资料、长期领域资料、通用参考资料，还是已经可以归档的历史内容。  
  
已探索 4 个目录，ran 2 commands  
  
初步看下来，这里面混合了会议纪要、下载的安装包、临时截图、正在推进项目的材料和几份标准文档。我接下来会先按“是否仍在活跃使用”进行第一轮分类，再给出建议路径和批量整理方案。

实践3：让 Agent 总结一个 Area 当前都积累了什么

有些 Area 是长期负责的，比如英语、软件工程、孩子教育、投资理财。这类目录的问题不在于“没有内容”，而在于内容太多了，久而久之自己都不知道里面已经沉淀了什么。

Agent 很适合做这种“盘点当前资产”的工作。它不一定直接帮你产出最终文档，但可以先把目录里的内容做一轮结构化总结，帮你建立重新利用这些内容的入口。

向 Agent 提问

1

这是我 Areas/软件设计 目录。你可以帮我看看这里现在主要沉淀了哪些内容？按主题帮我归一下类，再告诉我哪些内容已经比较完整，哪些内容还只是零散积累。

Agent 回复

1
2
3
4
5

我会先浏览这个目录下的子目录和关键文档，判断当前沉淀更偏向方法论、实践记录、工具使用，还是项目复盘，并整理出一个主题结构。  
  
已探索 5 个目录，ran 3 commands  
  
从目前看到的内容来看，这个 Area 里既有一些长期积累的方法论笔记，也有若干和具体项目相关但仍有复用价值的实践文档。我接下来会把它们拆成几个主题，并标出哪些已经可以整理成对外输出的文章或分享材料。

实践4：从一个目录里提炼周报 / 月报素材

很多人写周报、月报最痛苦的地方，不是“不会写”，而是回头找素材太费劲。尤其是当你的工作记录分散在会议纪要、草稿、截图、PRD、临时文档、代码仓库说明里时，人会本能地拖延这件事。

如果文件组织本身还算规整，Agent 就可以直接从目录里提炼候选素材，最后输出一个可编辑的 Markdown 初稿。

向 Agent 提问

1

这是我最近两周的工作目录。你可以帮我整理一版周报素材吗？先按“已完成事项、推进中的事项、问题和风险、下周计划”四个部分来归纳，尽量基于已有文件内容，不要凭空发挥。

Agent 回复

1
2
3
4
5

我会先查看最近两周活跃修改的文档和项目目录，提取其中能够反映工作进展的内容，再按周报结构组织成一版可编辑草稿。  
  
已探索 6 个目录，ran 3 commands  
  
目前已经看到几个高频修改的项目目录，以及两份会议纪要和一批方案文档。我接下来会优先提取能够代表实际推进结果的内容，避免把讨论中的想法误写成已完成事项。

参考资料

1. Agent：一切皆文件：https://mp.weixin.qq.com/s/ulmVG3_yrfy-7EofRgnyGw

其实，一直写Java，用Spring框架的同事，一定会觉得依赖注入就像呼吸一样。但是在其他语言的开发者看来却不尽言。

我在项目的开发过程中使用过Java，也使用过Go语言。见过很多写Go语言的同事对Spring框架嗤之以鼻。也被同事讲过写的代码Java味很重，emmm，学习一个语言就要学习它的最佳范式与哲学，这我无比地认同。

首先，依赖注入 != 依赖注入框架 ，比如

1
2
3
4
5

type Client struct {
  logger *slog.logger
}

client.logger = newLogger()

其实，这样显式地为 logger 赋值，本身就是一种依赖注入。 只不过，它是手动注入，而非通过框架自动完成。

如果完全不用设置，那就代表这个模块是单例的，举个例子，Java中的log4j2，绝大部分场景下都是单例的，通过配置文件来反向控制某个包下面的日志级别等等。

之前读过一本书有个很有意思的理念，就是”包变量/静态变量”是不好的，是违反物理规律的。

只是由于种种原因，在程序运行时，只存在一个实例。25年1月份，在一个Go项目中，我做的一件重构就是把原本的包变量引用替换成了成员变量，因为发现在运行中会存在多个相应的struct实例，他们对这个变量的需求是不一样的。

那么依赖注入框架呢？
其实Go语言也有很多依赖注入框架，如果有很多的strcut都要get、set，那建议还是使用依赖注入框架。我做的项目没有使用依赖注入框架，主要有两点原因

1. Go语言依赖注入没有形成统一的标准。
2. 其次，目前产品还没有很多的strcut都要get、set。

DI框架本身也有学习成本，这块框架我没有详细了解，如果能在工程组织，测试上大大简化的话，我还是很乐意用的

一方面，是Vibe效率的飞升：三天完成一个Demo，一下午Vibe一个Poc项目。
另一方面，是企业效率没有想象中的提升，似乎，没有AI辅助流程，对企业没有任何影响。

为什么？

首先，这是极具代表性的两个开发场景：
其一，单人开发，担任产品经理、开发、测试、运维角色，一人承担所有的责任。（即使GPT写错了付款接口你也只能责怪自己）。
其二，多人协作开发，分工明确，各自承担不同的角色与责任。

基于此，针对AI辅助开发，笔者分析整理了三个原因，这三个问题层层叠加，从模型能力到系统隔离，再到协作方式，构成了企业级 AI 提效的现实瓶颈。

一、模型、算力

模型的推理能力、支持上下文的长度，对工具的效果影响是天差地别的。企业出于对资产安全的考虑，往往会选择私有化搭建模型，这可能会导致如下两个问题：

• 内部模型参数量较小：推理能力明显低于公有云大模型，尤其在多语言代码生成和复杂语义补全上差距明显。
• 上下文长度受限： 受限于上下文窗口，AI 工具只能看到当前编辑文件或部分上下文，导致生成结果割裂。

  先进的理论、经验都是基于AK 47的，确定一定要基于AK 36继续优化么？

二、信息系统孤岛

在传统的逻辑下，将信息分隔到多个系统，进行精细化管理，通过人来串起整个流程，这无疑是非常优秀的做法。笔者也曾经将团队中的所有数据库相关实体定义集中到一个代码库管理。

而AI辅助开发工具通常运行在代码仓，单人开发模式下，我可以把设计文档提交到代码仓，典型测试集都提交到代码仓，编写代码需要的Everything，只要适合转换为文本模式的，我都可以提交到代码仓。

在AI辅助开发工具没有集成对应信息系统的情况下，需要开发人员手动提炼复制上下文到AI辅助开发工具，这和我再提炼提炼，以Chat的方式对话，有什么区别？

其实这一点在代码仓管理上也存在，Repo的分隔也存在这个问题，前端、多个语言的客户端、API的Yaml文件，进行精细化的管理。但CC、Cursor这样的工具无法看到全貌。

下一个我做的项目，我倾向于使用Mono Repo，充分利用AI工具提交，并且如果是AI相关项目的话，我倾向于使用Python语言。

但是我相信，如果多个系统都能与AI工具对接打通，给AI提供了更加结构化、质量更高的数据，理论上上限要高于所有东西以markdown格式放在代码仓库不同文件夹的做法。

三、工作流程

AI没有改变软件工程，只是把其中的很多工作加速到不可思议的地步。

AI只能加速单人闭环的工作，对人和人的交互没有帮助。

AI 当前的强项，是提升“单人闭环任务”的速度。但当任务涉及跨角色交互时（如开发与测试、测试与运维、产品与开发），AI 的作用显著减弱。

左图是人与人的交互，严丝合缝。如右边两张图所示，AI交付件还不能做到严丝合缝地对接，为了能顺利走完流程，蓝色、橙色，必须得有一方做出额外的工作才行。（当然，为了避免同事说你不靠谱，我还是推荐蓝色方做出额外工作。）

AI时代，应该尽量把一个工作的各个方面交给一个人，这样来减少人与人的交互，充分提高效率。

这和交给Agent足够的上下文的道理是相通的。

来看一个典型案例：微服务开发与测试的协同。一个典型微服务的开发、测试、发布上线流程如下：

产品与开发、开发和运维，这样的问题也存在，以编码举例子，主要是因为时间相对长，矛盾更加明显。

测试负责产品质量的出口，测试在自己的领域范围内，通过自己的理解，对整体的测试进行分层落地（基本接口测试与集成测试环节）。

图中共有四项活动：代码、单元测试、基本接口测试、集成测试。这个模式下，单元测试与基本接口测试存在能力上的重叠。对流程进行了如下优化（测试将测试设计左移，基本接口测试放在开发阶段，弱化单元测试。

从传统领域的角度来看，下面的方式，测试更早介入，且减少了重复工作。但是从AI辅助的角度来看，那个效率更高？

从AI辅助的角度，橙色的环节充斥着大量的交互，诸如代码中书写的测试要匹配测试的设计（通过方法名与用例Id匹配），开发要确认测试设计表达的含义等。当团队想要使用AI提效时，这个矛盾就被放大。尤其是当 模型能力不足 与 信息孤岛 并存时，协作复杂度被进一步放大。

当下，在笔者所在的团队，上下两种流程都存在。上下两种方式那种更好？笔者下意识地觉得当未来AI的生产力突飞猛进的时候，上面的方式会更好（这一判断源于相信人和AI协作的效率会远远大于人和人协作的效率），但是在当下，笔者想不清楚，也给不出答案。当前笔者针对上下两种场景，寻找集成了对应信息源、最合适的工具进行提效。

总得来说，企业要避免陷入 “工具因为流程导致效果不及预期”、”流程不会为没有效果的工具变更，让步”、”开发人员对工具没有信心” 的恶性循环。

总结

AI 在个人层面的高效令人振奋，但企业的整体效率并未出现预期的跃升。问题主要集中在模型能力、信息孤岛与工作流程三方面。前两者可以通过技术投入与资源建设逐步改善，而工作流程的变革则需要企业在思维模式与协作方式上完成真正的转变。

近日，在推特上看到了有关GitHub用两台服务器，部署了200万个pages网站的帖子，也想分享一下2019年左右，使用Nginx正向代理数千个配置文件的往事。

当时项目上主要用Nginx来做网络平面的隔离以及TLS的解码，无论是从外到内，还是从内到外的流量都会经过Nginx。

从外到内的流量虽然大，但是也就是几个端口提供服务。从内到外有个外出推送的功能，它是可以将不同用户的数据推送到用户的HTTP服务器，这里有数千个HTTP服务器，涉及到HTTPS的证书也有数千个，Nginx的配置就集中在这里。

每个用户变更HTTP服务器的时候也会涉及到Nginx的Reload，这和GitHub分享的场景也很相似。如果你的应用接受不了不定周期的Reload，不要采用这种方案。

在这个项目里面，我磨练了很多，对TCP、HTTP协议栈都有了很深的理解，也见识了各种各样的客户服务器，比如用C语言手写解析json的等等。

我还经历过一次这个规模级别平台的迁移，为了判断迁移后配置的准确性，写过脚本对这些http server一个一个进行测试。很怀念那时候的时光。

业务服务碰到的问题

主要就是海量客户的HTTPS Server多种多样，有些响应时间较长，有些可能还会定时关机。如果Server一直hang住，可能也会导致业务服务卡住。针对客户的HTTPS Server，长期发送不通的引入黑名单机制，每数分钟尝试通行一个业务，如果成功则从黑名单移除，不通的话继续在黑名单中等待。

生成配置文件时间长

由于Nginx服务上运营了数千个配置文件、数千个证书，这导致每次Nginx容器启动的时候要从配置中心/证书中心逐个获取，未优化前这个时间最长可以达到20分钟。通过批量拉取，挂载虚拟机路径缓存的方式解决。这避免了每次容器启动都从配置中心逐个拉取文件，启动时间从20分钟降到3分钟左右。

安全

安全主要就是先保护自己，避免推送到一个内网地址把系统自己打爆。比如恶意客户拿到了Kubernetes API Server的地址，配到海量业务推送上。其次，tls上证书，算法等级，是否过期等等。

HTTP请求的各种错误

connect() failed(110:Connection timed out) while connecting to upstream

Nginx尝试发起TCP连接到HTTP Server，但是没有收到SYN+ACK响应，最终超时。

connect() failed(111:Connection refused) while connecting to upstream

Nginx 发起了 TCP 连接请求，收到了 RST 响应 —— 即目标主机明确拒绝了连接。

upstream prematurely closed connection while reading response header from upstream

HTTP Server接收了TCP连接，但是没有回复HTTP响应。

peer closed connection in SSL handshake while SSL handshaking to upstream

Nginx 在与上游建立 TLS 握手的过程中，对端在握手尚未完成时主动关闭了连接。

SSL_do_handshake() failed(SSL: error:140770FC:SSL routines23_GET_SERVER_HELLO:unknown protocol) while SSL handshaking to upstream

Nginx 与上游建立 SSL 握手时，收到的响应数据并非 TLS 握手数据（例如是纯 HTTP 响应），因此握手解析失败。

TL;DR

笔者推测Palantir起初以支持定制代码运行为基础，在构筑自己部署平台（Apollo，Palantir GitHub上也有很多开发者构建、Lint工具）的同时，逐渐抽象出Dataset、本体、Function、Action API，打造了坚实的Foundry平台，让应用从定制化开发逐步“长在平台上”。最终，Palantir 推出人工智能平台（AIP），实现数据驱动的智能决策。

前言

近年来，Palantir 无疑成为数据分析领域的焦点之一。作为一家以解决复杂问题为核心的公司，Palantir 为政府、国防和企业客户提供了强大的数据整合与分析能力。Palantir 的核心产品 Foundry 是一个面向数据整合与分析的平台，它如何从最初的定制化开发逐渐演变为如今的通用数据智能平台？笔者尝试基于公开资源推测梳理 Palantir Foundry技术平台的演进路线，分享一些分析与推测。本文仅代表个人观点，欢迎读者交流探讨。

阶段0 定制代码运行

从Palantir的Offering来看，其核心始终是为客户解决复杂问题，拥有大量的FDE。合理推测Palantir最早其实以定制代码运行交付作为基础，通过高度定制化的软件开发满足客户在政府、国防和企业领域的特定需求。

阶段0，此时都处于定制开发状态。

阶段1 从定制代码运行到Palantir平台运行

正如《人月神话》中所说，优秀的程序员都会有自己的library库，优秀的定制开发商也倾向于提炼可复用的技术框架。

对于定制代码来说，我们把定制代码分为编写态和运行态

• 编写态，对应Palantir Code Repositories，可以看到Palantir的很多东西，其实跟Git很相似，有分支、合并等等。
• 运行态，将Palantir Code Repositories的代码构建运行，支持多种触发方式，比如通过API调用来执行，定时执行等。
  Apollo 平台进一步支持多环境部署（如云和边缘）。
  

阶段2 数据的平台化存储和管理

当开发工作逐渐迁移到 Palantir 平台后，数据的存储和管理成为下一个重点。如果代码已经运行在平台上，那么数据为什么不能也存储在平台中呢？

Palantir 在这一阶段引入了 Dataset 和本体（Ontology）模型，构建了平台化的数据管理能力。Dataset 作为数据的核心容器，支持结构化和非结构化数据的存储；本体则定义了数据之间的语义关系，为数据提供了更高级的抽象层。此外，Palantir 接入了时序数据库，增加了对时间序列数据的支持，满足了金融、工业等领域对实时数据处理的需求。

同时，也把数据集的变更增加为一个触发条件。例如，当某个 Dataset 发生变化时，平台可以自动触发预定义的操作，如运行一段代码或更新其他数据集。

阶段3 抽象Action Function

在本体已经定义了DataSet以及数据集之间关系的基础上，通过Action、Function的定义，同时Action、Function可以通过拖拉拽简单地生成，无需书写代码。对于难以无码的复杂逻辑，还可以通过定制代码来书写。

其实Workflow和Pipeline都是在更高层次、更简便地操作代码的手段而存在，底层实现上：

• Pipeline = Datasets+Builds+Schedules
• Workflow = Schedules + Builds + Jobs

阶段 4：AIP 的智能决策赋能

在Foundry坚实的基础上，Palantir 2023 年推出了 AIP（人工智能平台）整合大语言模型（LLM）与 Foundry 数据，自动化复杂决策。其核心功能包括：

• 自然语言处理：用户通过对话界面查询数据或生成分析，如“预测下季度库存需求”。
• 自动化工作流：基于 Ontology，AIP 驱动智能决策，例如优化供应链或调度资源。
• 实时推理：结合时序数据，AIP 支持动态预测，如医疗资源分配或工业故障检测。

总结

图：笔者设想的企业使用Foundry路线图

本文分析了Palantir Foundry的技术实现路径，笔者认为Palantir Foundry 的技术演进展现了一个从“定制”到“平台原生”的清晰路径。应用从分散的定制代码，逐步迁移到平台上运行，扎根于平台的数据和触发机制，最终成为完全依赖平台功能的原生应用。

令人深思的经历

曾经历过这样的事情，平台侧要求应用提供满足平台特有格式的交付件，经过多次协商，最终还是应用侧与平台侧一起开会，由平台侧帮助应用侧输出。

另一件事，Kubernetes Yaml以其独特、强大的合并属性能力闻名于江湖。应用侧对Kubernetes Yaml不熟悉，新手想要把环境上的Yaml导出直接作为标准交付件，虽然也行，但是包含了很多噪音，环境上的id、环境上的annotation、时间戳等等。

私有化格式的交付困境

越来越多的软件将自己定位为”平台”，无论是微信、飞书这样的国民应用，还是各类企业级软件。但平台交付的过程中，一个普遍存在的问题是：许多平台要求合作伙伴或第三方开发者使用其私有化的交付格式。这种私有化格式往往存在诸多问题：

• 学习成本高，难以掌握。
• 文档不完善，依赖平台方支持。
• 迁移困难，形成供应商锁定。
• 最终往往仍需平台方投入人力协助。

软件交付应该标准化

软件交付应该使用标准的格式，这有助于降低合作伙伴的接入成本，提高自身的可扩展性，尤其在AI辅助研发的现状下，采用标准的格式更有利于AI理解和生成代码。

如果实在要使用私有的格式，可以对标准格式做一些裁剪/扩展（Kubernetes的annotation），将标准格式转化到私有格式。

在软件开发中，健壮的异常处理是编写高质量代码的关键。本文将探讨现代编程语言中的通用异常处理方法，帮助你优雅地处理异常并写出健壮的代码。我们将不拘泥于某种语言，而是讨论一些普遍适用的策略。

异常链概述

现代编程语言通常将异常视为一条单向链表，链表中的节点包含根本原因和相关的上下文信息。例如：

graph TD
    C --> D[MicroServiceError, call user service failed]
    B --> C[DatabaseError, select * from user failed]
    A --> B[HttpError, http://localhost:6379 failed]
    A[SocketError, localhost, 6379 connect failed]

异常就这么向外传播也不错，但是抽象是会泄露的，正常的时候顺风顺水，异常就需要判断一下，比如一个很常见的需求，文件已存在异常，就当做成功处理，用Java来写就是这样

1
2
3
4
5

if (exception instanceof FileAlreadyExistsException) {
    log.info("file already exists");
    return SUCCESS;
}
throw exception;// or wrap it

综上来看，我们对现代编程语言的需求就是，能组织异常链，判断异常是否是某类异常，把异常用字符串的形式打印出来。

当我们在构筑一个library的时候，应该尽可能保持完整的异常链，除非你认为这个异常在library内可以处理，比如上面的情况。并且应该在项目的README，或者项目的某个文件中，详细地列出本library可能抛出的异常，以及异常的含义。

我们在opengemini-client-go中就有这样的例子，我们在errors.go中定义了所有可能的异常，以及异常的含义。

有些时候，我们构筑的不是library，出于隐藏内部实现或者是向终端用户隐藏逻辑上的低级错误，我们会对异常进行处理，比如常见的

1
2
3
4
5
6

if (exception instanceof DuplicateKeyException) {
    log.info("duplicate key");
    return new ServiceException("already exists");
}
// many if else
throw new ServiceException("unknown error"); // or just internal error

题外话，由于Java只能判断本级的异常类型，你会经常看到getCause的代码，比如Apache Pulsar项目中的

1
2
3
4

if (exception.getCause() != null
                    && exception.getCause() instanceof PulsarClientException.InvalidServiceURL) {
    throw new MalformedURLException(exception.getMessage());
}

包括层次一多，甚至可以看到递归代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

private static Throwable mapToBkException(Throwable ex) {
        if (ex instanceof CompletionException || ex instanceof ExecutionException) {
            return mapToBkException(ex.getCause());
        }

        if (ex instanceof MetadataStoreException.NotFoundException) {
            BKException bke = BKException.create(BKException.Code.NoSuchLedgerExistsOnMetadataServerException);
            bke.initCause(ex);
            return bke;
        } else if (ex instanceof MetadataStoreException.AlreadyExistsException) {
            BKException bke = BKException.create(BKException.Code.LedgerExistException);
            bke.initCause(ex);
            return bke;
        } else if (ex instanceof MetadataStoreException.BadVersionException) {
            BKException bke = BKException.create(BKException.Code.MetadataVersionException);
            bke.initCause(ex);
            return bke;
        } else if (ex instanceof MetadataStoreException.AlreadyClosedException) {
            BKException bke = BKException.create(BKException.Code.LedgerClosedException);
            bke.initCause(ex);
            return bke;
        }

        return ex;
    }

Go在这里易用性做的不错，支持了errors.Is和errors.As，可以判断异常链中是否包含某个异常，也可以直接获取异常链中的异常。不过如果异常链里面有两个一模一样类型的异常，你想精准取到其中一个就比较困难，不过这在实际场景中非常少见。

这里，我们说异常链发生了变更，那么什么时候打印日志也比较明确了，当异常链发生变更的时候打印，保证完整的堆栈信息用于问题分析。这也可以保证在一条链的过程中，有且仅有一次打印日志。

在异常链发生终止，比如转化为http content，或者是print到console的时候，要不要打印日志呢？这个问题有些见人见智，这取决于你的用户在report问题的时候，会不会携带http content或者是console output，如果不会，那么你就需要打印日志，如果会，那么你就不需要打印日志。

Java里面，比起将底层的error抛出，我们更倾向于定义一个符合本library抽象层级的异常，并在方法的签名中只返回这个异常，一方面使得下层library的异常如果发生变化，本library依然是编译兼容的，另一方面也更符合抽象层级。

但是在Go里面，事情就更复杂一些，我愿意称之为类型的细化具备传染性，一旦你将某个方法的签名不返回interface，而是返回一个具体的类型，比如

1
2
3
4
5
6

func (c *Client) CallService() (Result, *ServiceError) {
    if failed {
        return nil, &ServiceError{Code: 500, Message: "service error"}
    }
    return result, nil
}

然后有一个方法调用了它

1
2
3
4
5
6
7
8
9
10
11
12
13

func main() {
    err := MakeFriend()
    if err != nil {
        panic(err)
    }
}

func (c *Client) MakeFriend() (Result, error) {
    err := io.Read("friend_list.txt")
    if err != nil {
        return nil, err
    }
    return CallService()    

这下就麻烦了，当*ServiceError转化为error, nil的ServiceError指针转化为error的时候就不是nil了，这很致命，是的，这非常致命。即使CallService()成功了，main函数还是会panic。

把这个叫做传染性还是比较准确的，异步的代码、鸿蒙的ets都具备一样的性质，他们会不断向上传播，我对这个词还是比较满意。

综上，Go里面，我们可以构筑具体的异常，但是在不能确保上层一直都是用这个细化类型的情况下，接口还是返回error interface。

漫谈了许多，我简单做一个总结

• 现代编程语言的异常是一条链
• 现代编程语言应该具备构筑异常链，判断异常是否是某类异常，异常打印的能力
• 设计符合抽象层级的异常
• 构筑一个library的时候，尽可能保持完整的异常链，在项目的README，或者项目的某个文件中，详细地列出本library可能抛出的异常，以及异常的含义
• 在异常链发生变更的时候进行日志打印

消费组名称

• 共享消费者使用微服务名称，比如(DeviceManager)
• 广播消费者使用微服务名称+唯一标识，比如
• kubernetes部署场景下可以将pod名称的唯一部分作为唯一标识，比如下图的nginx可以使用5d4f5c59f8-7hztx作为唯一标识

  1 2 3 4 5

  $ kubectl get pod NAME READY STATUS RESTARTS AGE nginx-deployment-5d4f5c59f8-7hztx 1/1 Running 0 2d3h nginx-deployment-5d4f5c59f8-xvbnm 1/1 Running 0 2d3h redis-5f67c8d8c9-4g2h3 1/1 Running 0 10h

  • pod的IP地址
  • UUID

数据库表

• 数据库表名使用单数。
• 数据库的主键，要考虑对应实体物理上是否唯一。
• 数据库可以分为多个列组合唯一、单列唯一、是否有唯一索引、是否有二级索引。