本周的心态还是平和了一些,因为团队内部的事情得到了部分解决,但是我对于工作从来都是觉得 bullshit job,早日退出游戏是正道,通过其他渠道实现工作收入的替换。

本周观影

台湾空姐花3万买房独居东北小城:我不想回去

自己觉得过的好才是好,年轻人有自己的想法和活法,都是正常的选择,我希望我孩子也是,我也不会干涉年轻人的生活。

看电影时,我到底在期待什么 和观影无关,看到这篇我只是突然想到自己有一阵子没看电影,别说去电影院了,能在家随时有合适的频道看自己想看到的,也是一件很幸福但也很不容易做到的事,一方面是渠道,一方面是设备和家里的环境,也许常去电影院反而是一件相对容易的事情,但目前我好像还做不到,如果我要去和博主一样就选早场。

本周阅读

能够安静下来好好看书,而不是为了读而读,不是完成任务的心态,能做到这样我觉得达成了理想的状态,现在我回顾过去自己的心态其实是拿着书,但是急急忙忙想赶路的节奏,也许我的脑子已经腐化了,需要修正自己。

  • 《大唐双龙传》:到洛阳了,偷了和氏璧,暂停不读了。
  • 《笑傲股市》:一开始讲图表,不适合在 Kindle 上读,而且我其实不喜欢看图表,其实我还没资格说喜不喜欢,因为我就不懂,所以还是得坚持读读,只是需要在电脑上去完成,改读《How to Make Money in Stocks A Winning System in Good Times and Bad, Fourth Edition 2.pdf》
  • 《張忠謀自傳全集》:在 Boox 上,有空慢慢读

在雪球上看人推荐了《1929: Inside the Greatest Crash in Wall Street History—and How It Shattered a Nation》,也了解作者 Andrew Ross Sorkin 的其他书籍,如:《大而不倒》(英文《TOO BIG TO FAIL》)。

本周播客

E56 债券收益越来越低,但它为什么仍然重要?|中国大类资产投资 2025 年报

不同资产种类相关性低,做个组合;股债比例,债券在组合发挥的优势和实际作用?过去五年做个时间段,中国股市表现不好,债券表现还不错,海绵、负相关或不相关,有利于控制回撤(提升夏普比?);完全不相关的资产是不存在的;大类资产投资年报有中国各类资产相关系数的概览,债券和股票的相关性低;债券投资人来说利率上行,价格是往下走的,债券是固定利率,适合通胀密切相关的,人民币的币值,如果买了美债,美元和人民币还不一样,利率/汇率和通胀风险,不要轻易看一个指标去投资,可以投中国债券为主,投一下全球的债券。

久期:衡量债券现金流平均回收时间及其利率敏感度的指标。久期越长,价格对利率波动越敏感。

看到的一些问答:

好奇请教一下,如果我以 10 年为投资周期,按照历史数据,那我是否就应该把所有资金都配置到股票宽基指数里,因为按照历史数据,股票收益就是比债券高很多?陈Peng: 如果你不需要用钱,而且你对风险 ,10年路途中的回撤 波动,有100% 的心理准备不动摇。 就可以考虑 80-90% 股票配资

第一,投资债券,利率上行,资本利得为负。2022年美债利率上行,美国长期债券下跌15%~20%。需要很多年的高票息,才能弥补资本利得的损失。
债券价格下降幅度 ≈ 利率变动幅度 × 久期。
比如债券久期10年、票息利率3%,现在发行利率4%,债券价格下降 1% × 10≈10%。
第二,债券是固定利率,跟通胀密切相关。如果买美债,增加了汇率、不同国家的通胀风险。可以做分散,以中国债券为主、海外债券为辅的全球组合。
过去2年美债收益8%,但赚取的收益换回人民币,美元兑人民币的汇率下跌8%,等于没有赚钱。

江鋆晨: 大模型记忆,KV Cache,清华姚班,CMU,教授,开源,视频流媒体

这个聊的听着挺舒服,内容我其实不是听的特别懂。

本周胡思乱想

  • 要善良,但不要乱爱。
  • 逐步缓解了情绪,但是我会记住周末的时刻和教训的,我会尝试对我自己做点改变。
  • 早上突然想到读书,我总是在完成一个任务似的,回头看好像做任何事情都是,我的人生这么无趣吗?要检点和反思。
  • 反复在思考上面的问题,人生不是考试,不是做题,不要把自己活成小镇做题家,要的是有趣和意义的人生,放慢而不是匆匆赶路,享受而不是当成修炼和去经历苦难,一个阶段做一个阶段的事情,但一定不要有考试和完成任务的心态。

本周投资

  • 美股方面有了变化,但是本周在另外一个方面有了一个新的起点,后续看是不是可以在灯塔国重新开始。
  • 听了投资 ABC 一期关于债券的播客,对控制回撤也许考虑继续买点易方达的美元美债(目前是 100刀上限),后续也再看看富国的美元债(RMB)。
  • 在考虑通过 PE/PB 百分位以及股息选择一些标的,不同行业的 5 个标的(医药/食品行业我不太敢碰,问题太多),包括目前持有的招行,还可以选 4 个标的,每个标的一步到位的买入(比如:5w),然后逐渐加仓或卖出(卖出的标准是啥?涨幅到 10% 止盈,跌幅 20% 止损 ),看能做到什么样的收益。

本周文章

你不知道的具身智能:从小机器狗到 Optimus

这种动手做的过程还是挺有意思的,对于具身智能有了具象的体会和了解。

Moving my app subscriptions to Europe

欧洲也在和“脱钩”过程中,需要技术主权(tech sovereignty),博主聊了其不用个人的服务转到欧洲的一个过程,包括 phots、mail、password management 和 search engine 等,更多信息也可参考下面两篇:

A new era for software testing

LLMs offer a new way to do QA on top of the existing testing methodologies. The idea is to create a markdown file where an AI agent is asked to work as a QA engineer, performing a number of manual testings on the new release.

The agent is asked to check the long list of QA activities especially in light of the added commits, starting with an inspection of the changes and with the identification of what could be affected, so that the QA pass specializes trying to find specific regressions.

所以人就是编写相应的 QA activities,以 markdown 的格式,同时给与足够的上下文信息,编写测试代码是不是就没必要了?也是一个思路,项目上可以有些尝试。

MCP is dead

经验不足,没太看明白,不过通过 MCP 获取信息给到 LLM 作为上下文这个角度来看,肯定不如从 workspace 直接拿到足够的上下文信息更加高效和丰富。

TL;DR: MCP eats context, has low reliability, and overlaps with existing CLI/API.

Do AGENTS.md Files Actually Help Coding Agents?

和我过去的认知类似,但是没想到不写或让 Agent/LLM 生成的 AGNETS.md 其实也还好,不过写个 Agent 的 README 从控制其行为上来说我觉得一定是有必要的,而且是一个索引,但需要保持内容上的简洁。

My takeaway is that repository-level context files should probably be kept shorter and more specific and perhaps ideally hierarchical (e.g., “if you do x, check this other context file y.md, otherwise ignore it”).
Of course, the problem here is that the LLMs and harnesses are a bit dated by now, and it would be interesting to redo this study with the latest harnesses and LLMs.

Tool, skill, or subagent? Decomposing an agent that outgrew its prompt

When does logic belong in a tool, a skill, or a subagent? You'll learn the decision framework by doing: inherit a 402-line inventory agent, decompose it live on Claude Managed Agents, and run evals after every change to see what flips.

这是 Anthropic 公司一个人的一个分享,我自己看下来就是展示了一套方法和工具,结合 Claude 分析 一个 agent 的做法,同时说了自家的 Claude Managed Agents - CMA(什么是 Claude Managed Agents), 利用 CMA 可以部署 agent,分析过程如下:

  • 通过 eval (uv evals --agent before) 一个例子的 agent(stock management agent),继续分析 themes(用的 prompt:what are the themes of why the issues happened (RCA));
  • 然后接着通过 prompt “Let's start with #1. Look at @agents/starter/agent.py. Any thoughts on the system prompt? Can I use Skills instead of a long system prompt for progressive disclosure?” ;
  • 接着分析 tools 通过 prompt “what can we do about the tools? I want to lean into bash, read, and write instead of rigid tools.”,CMA 自带的 tools 可以提供不少能力,也提了 MCP;
  • 继续分析 subagents,CMA 天生具有 logging 和 observability 能力,不一定需要 subagent;
    最后结果是简化 agent 为:1 agent,5 skills(all business logic 被替换为 skills),agent tool set(bash、read 和 write),用更少的 tokens 更高的 agent 评分;演示用到的相关 Gitlab code repo

帮大家总结了一下凌晨的苹果WWDC26

好的品味,优异的质量,无敌的生态,以及持续不断的创新,Cook 退了,看看未来 10 年会如何。

周末还是在持续调整中,因为工作上的一些烦心事,我还是没走出来,但是希望我自己快点浮出来。

本周观影

  • A 7-day explora tion of La Palma volcanic island led me back to a cliffside cave by a hermit.:博主到了 La Palma 岛,一个火山岛,阳光、火山、海岛、彩虹还有茂密的树林,太好了;下山路边看到德国人在捡蘑菇,也捡了两种蘑菇;德国嬉皮士社区;农家乐吃饭(吃了几家不同馆子,博主是会吃懂吃的),喂鸡野生乐园;火山徒步,盐田,Cesar 的印记无处不在;野外哲人(耶稣还是萨满?),更多的 peace,简单和大自然连接;期待博主下一个岛(Gran Canaria 大加纳利岛)的视频。

本周阅读

我发现自己现在技术方面的书读少了,要想想为什么,回头看看是否是真的没必要了,还是我自己方向和兴趣变了,后面的 10 年我要给自己准备点什么;我要告诫自己的是要持续并坚定的做点啥,而不是一直变来变去,阅读和输出可以可以助力。

  • 《大唐双龙传》:看到一战成名,去了任少名,会见地剑宋智,再见宋玉致。

下面的书本周没啥进展。

  • 《原则》
  • 《Sam Zell - Am I Being Too Subtle (适度不敬 : REITs之父萨姆·泽尔自传》
  • 《笑傲股市》

这个最近看到的站点:软件设计的哲学 · 可视化讲解,想重读一下《A Philosophy of Software Design》— John Ousterhout,有第二版了。

本周播客

E238 你还记得上一次停下脚步,认真感受世界的时候吗?和任宁聊一聊观鸟

我过去一任老板包括现在也偶尔一起吃饭和外面徒步玩玩的,和孩子一起异常投入观鸟这个爱好,所以这期播客我有兴趣听听,同时下面这段话我也真心认同,利用周末时间我也要多出去走走,无论何种爱好,只有是健康积极向上的都值得投入和花心思,直到热情燃尽,寻找下一个。

这也是我想和任宁聊观鸟的原因。观鸟当然是在看鸟,但也不只是看鸟。它让我们重新打开眼睛和耳朵,重新注意到附近,注意到季节、物候,也注意到一个不完全以人为中心的世界。

价值切成长是一件容易的事情;成长切价值,非常难

还在听,张翼珍,主要是做动量(会持续的给出申万一级行业相对强弱一览),也看到了 CTA 这个新概念,简单了解了一下。

CTA策略,全称“Commodity Trading Advisor”,是指在期货和期权市场上,通过趋势跟踪、基本面分析、套利等策略,以获取绝对收益为目标的投资策略。CTA策略的投资标的包括商品期货、金融期货、外汇期货与期权等

作者:_至简量化_
链接:https://xueqiu.com/8185159194/279719557

本周胡思乱想

  • 我的周末日子质量有待提升,太多时间在屏幕前了,还是多出去走走,可以漫无目的。
  • 不确定是不是聊太多了,感觉都不对,但是不说很多时候不符合我个人风格,无所谓对错,但是一定要坚持个人的风格,以及对事情的判断。
  • 带团队这一块,有时候我是严厉的从来也是容不得沙子,可能我个人从小的经历来看情商这一块的培养是不够的,所以本周对我的教训是如果对人一开始有疑问,就要疑人不用,用人不疑,我是一方面有纠结,一方面又是给了各种机会,以后一个原则,建团队就是要用自己人和可信的人,而不是一直犹犹豫豫给自己不断带来困扰的人,目前就是冷处理当下的困境,早点完成替换,逐渐边缘化;下面是 ChatGPT 给我的一些建议。

你不像是“没情商”。
你更像:
对事情和标准太认真
这种人在技术和架构岗位其实很多。
但带团队以后,要学会“管理不是证明自己对,而是控制团队系统成本”
包括:

  • 情绪成本
  • 沟通成本
  • 不稳定成本

团队里“可信”和“高能力”不是一回事,长期来看中上能力 + 高可信通常比高能力 + 高不稳定更有价值。
“团队不是靠‘好人’建立的,而是靠‘可靠的人’建立的。”
这个“可靠”包括:

  • 能力
  • 责任感
  • 沟通
  • 稳定性
  • 对团队的正向影响
    你现在其实已经开始从“技术负责人”往“真正的组织负责人”转变了。

本周投资

  • 本周做了大的调整(卖出了三个标的),今天看还是不错的一个时机,也持续分析了下周如何操作的问题。
  • 富国的一个 QDII 基金的每日限额异常快速的降,可见政策的影响,我买入了部分,但没多少,不是一个好的时间点(不过后续能买入的量也少了,只能是通过 DCA 了);标普 500 的没额度了(可以从招行 App 的理财频道查不同国家和不同基金的 QDII 额度)。
  • 周五大跌,buy the dip 还是啥,行业进入轮动,公用事业和消费上?下周见。

本周文章

福耀玻璃长期逻辑的再认知

球友 C4Cire 分享,不是说我对福耀本身有兴趣,而是对齐分析框架和思路的学习和推敲,仔细学习一下现金流那段的分析,潜在也在分析企业文化,通过内部刊物这种视角也是看公司的管理层和企业文化的视角。

一、关于穿越的假想段子
二、对半年报的看法
三、汽车玻璃的再认知
四、汽车玻璃行业特点与趋势再讨论
五、福耀玻璃的竞争优势与长期逻辑
六、福耀玻璃的现金流问题
七、FYSAM的相关问题
八、福耀强在哪里
九、福耀为什么强

4 天搭出 Android AI 聊天 App

一方面是 AI 时代编程模式的探索,从设计(UX 和方案)、研发、验证和上线的全链路闭环,一方面是人在这个过程中的参与,两个方面缺一不可,前者要探索适合公司和产品项目的交付模式,包括工程实践和组织架构的变换,后者是关于人的重新定位,以及能力矩阵的变换。

所以我不觉得 agentic coding 会让移动工程能力失去价值。更可能发生的是:低杠杆的实现工作会变少,高密度的架构判断、计划审查和验证设计会变得更重要。移动开发者需要适应的重点,会从写更多代码,转向更频繁地为代码生成的方向负责。

这也回答了第一节里的问题:外部 Android 的工具链、依赖管理、验证环境和 Meta 内部工具链都不一样,但 agentic workflow 的核心模式没有变:找到目标,拆解目标到各个阶段,再写设计和实现计划,执行中不断把人工检查变成自动化验证,最后验收。这个 4 天实验验证了这套模式在外部工具链下依然成立。

Pioneering the Agentic Shift Within Salesforce Engineering

看看 CRM 巨头在 AI 时代软件研发如何做转型?是否有值得我们学习借鉴的地方?去除 token 限制,PR 持续的反馈,SDLC 的重新思考和实践,最佳实践的积累,质量和速度双提升。

Key Takeaways 要点

  • Autonomous tools are now writing code, reviewing pull requests (“PRs”), and driving deployments across the software development lifecycle. 自主工具现在正在编写代码、审查 PR 并推动整个软件开发生命周期的部署。 
  • Standardizing on Claude Code and removing token limits improved output and quality simultaneously — more shipped, fewer incidents, and fewer bugs. 对 Claude Code 进行标准化并消除 token 限制,同时提高了输出和质量 — 更多的发布、更少的事件和更少的错误。
  •  An agentic workflow allowed a product team to complete a 231-person-day migration in 13 days — 18 times faster. Agentic 工作流程使产品团队能够在 13 天内完成 231 人/天的迁移,速度提高了 18 倍。
  • We’re still in the early stages of redefining how the roles across engineering, product, and design will change. 我们仍处于重新定义工程、产品和设计角色如何变化的早期阶段。

科技爱好者周刊(第 399 期):中国 AI 大厂访问记

从美国人视角看中国的发展,还是有点意思,需要这样的交流和观察,中美现在这种趋势下,是逆全球化,主要受伤的还是我们自己,这个过程中我是否可以真的走出一条不同的路,存疑;另一方面,我们出不去也是最大的问题,我们的体系和价值观以及和这个世界的接触交流,期望我们更加开放和包容,能够融入全球的价值体系和商业体系。

今年5月上旬,一个美国访问团来到中国,访问了14家 AI 和机器人公司。
访问对象包括 DeepSeek、月之暗面、MiniMax、智谱、字节跳动、阿里、蚂蚁、小米、零一万物、宇树、魔搭社区等。
所有成员都是科技分析师,回到美国后,每个人都写了访问观感:Kevin Xuafra WangFlorian BrandNathan LambertAzeem AzharLily Ottinger and Kai WilliamsJasmine SunLingua SinicaCaithrin
这些文章有很多有意思的内容,我做了一些摘录。为了保证阅读体验,就不单独注明每一段的出处了。

周末在老家,看望家里老的,也是离开都市一下,换口气放松一下,最近几年回得多,每次回总期望自己可以早点退出“游戏”,AFK 是最好的选择。

本周观影

  • 我用4天,重走了这条曾经撑起一个国家命运的悲壮公路:滇缅公路,云南驿、飞虎队、机窝和惠通桥,之前没仔细了解过这段历史,听着博主的讲解,从昆明开始走一遍战时重要的运输线。重返滇西1944,我终于理解了一寸山河一寸血的历史分量:松山,激战的地方,中国远征军值得怀念和敬佩;腾冲,龙江大桥,滇西抗战纪念馆,腾冲战役;芒市,采访修路工的下一代,南侨机工,中缅国界畹町桥。这个博主很实在,拍的说的都很不错,推荐。
  • 合集·爸爸妹妹中国之行:今天看了好多这个中德夫妻的视频,这个系列是德国老爸和妹妹来中国,玩了北京和云南,是博主精心安排适合这个老爸和妹妹的路线,特别是在北京都是传统的路子,真好;也有带着老妈游中国的剧集,也挺好。

本周阅读

  • 《金融怪杰》:断断续续读完了,艾迪·塞柯塔、威廉·欧奈尔、大卫·瑞安和布莱恩·吉尔伯这四个人让我很有共鸣,对我个人有启发和帮助。
  • 《大唐双龙传》:读过好几次了,晚上醒来或平常想休息一下的时候,总会用 Kindle 读一下,我喜欢武侠的世界,大唐是我非常喜欢的一部,喜欢徐子陵和寇仲所经历的各种,特别是武学上的奇遇和进步,黄师的各种读了不少,最喜欢的还是大唐;我也喜欢金庸的《笑傲江湖》和《射雕英雄传》。

本周播客

E55 都说 A 股全是情绪、没有价值,是真的吗?|中国大类资产投资 2025 年报:数据说话,长期看一定是有确定性;每个人的投资风格还是取决于个人,我个人认同 Buy the Dip and Dollar-Cost Averaging (DCA) 结合,寻找确定性的标的加上指数方面的投入,但一定不要亏钱,用短期用不上的钱去投资,可以融资上杠杆,前提是自己可以扛得住风险。

随着持有时间越长,获取历史长期平均收益率的确定性越高。
四方法分解重要结论:

  1. 盈利增长是A股长期收益的核心动力;
  2. 长期持有权益资产能够获得合理的风险补偿;
  3. 股息收益率逐步提高,长期收益的稳定性与可持续性正在改善;
  4. A股长期收益与实体经济高度匹配。

关于白酒是周期见底还是永久衰退的一次审视:还没听完,学习一下白酒行业的分析,茅台虽然跌了不少,但一直是投资市场上的话题,段总也是一直推荐,有高股息和高确定性,成长性到了这个阶段可能是最不确定的了(回头 10 年来看是非常好,当下见底之后如何反弹,是不是后续还有一定机会,不乐观),今年五粮液改了去年财报的做法也是让市场对于这个行业有了更多的负面看法。

No.201 中国高铁简史:中国高铁的发展史,到底我们要怎样的发展,如果需要牺牲三代铁路人的话这是否值得?通过转让技术,获取自己的发展,再进行输出,这种路线是良性的吗?能赢得世界对我们的尊重吗?

本周胡思乱想

  • 要赚钱不要嫌麻烦和辛苦,所有的苦逼都是为了当下的自己和未来的不苦逼。
  • 周末还是有点焦虑和无聊的感觉,还是不懂如何享受孤独和无聊的时光,总是想着做点啥。写作和阅读对我一定有用,还要就是有意识的多出去走走,漫无目的的走路和骑车,消费点啥,放下心里的执念和任何电子设备,远离信息焦虑和一些执念。周日下午出去跑步走路,刻意离开了电子设备,以及出去走了走,好多了,就该这么过。
  • 投资来说,我觉得是个人生历练,非常好的一种悟道,对于锻炼自己的心性和认知也很有帮助;美股/A 股,可能风格不一样,投资手段和策略也不一样,但是有些核心东西,自己本身的投资理念和框架我觉得是可以互相复用的;有人也能做到 20~30 倍的收益,能做是太牛了,但还是取决于个人的情况,眼光、赌性和其他市场的因素,我个人的理念来说挺难做到的。
  • 回顾了一下最近的状态,早上有 FOMO 趋势,舍本逐末,看各种信息和资讯,投入太多了,早上就花费了大量精力,人反而早早陷入焦虑和疲惫的状态,容易出各种问题,调整一下。
  • 还是继续不断寻求新的可能,不要放弃。

本周投资

  • 坚持对 SaaS 的判读(企业一定需要,AI 能解决部分问题,但是企业内部的人、组织体系、年度要花钱和各种政治问题等决定了 SaaS 只是暂时低估,核心的当前剩余履约义务(cRPO)指标健康就是好的投资机会),继续做了一定的投入,目前看是对的一个判断;美股在科技板块不同方向持续轮动中,存储、光、SaaS、MAG7 外加特总的喊话(如:Dell),但同时巴菲特提的教堂和赌场,一直在我脑子里打转,我自己一直和自己在对话,是个修行的过程。
  • 基金方面做了一些调整,减了部分日经,加了部分科技方向的 QDII,不过 QDII 还是要考虑汇率方面的因素。
  • 下周看看软件方面被砸的洼地公司,看看基本面和核心财务指标,考虑抽取部分第一层资金往第三层放一放(违背了我自己的原则,第一层不卖出),如果有机会,不然也没其他资金了。
  • 国内我等着“大一点”的机会,看着板块轮动来轮动去,一波一波的,规律就在那,一般人不是全职的真的挺难抓得住,我的原则是不做右侧。

本周文章

How to set up an AI-native organization

Agent 之间的通讯,以及共享上下文(各种信息,包括统一的 tasks),实现多 Agent 协作很重要;文中分享了 Agent first 模版,有多 Agent 模版以及 handoff https://github.com/awebai/agent-first-company-template

也看到了这个视频 How to Build a Self-Improving Company with AI,如果要围绕 AI 去做当下的事情,组织架构以及工具平台的研究,包括方法论和体系的变革,都是必不可少,不然就是旧瓶装新酒,没啥本质的变化大,大部分公司就是干点提效的事情结束,只能走到这一步了;真正需要的是燃烧 Token 而不是人头,是 Token 账单让你心慌,尽可能的扁平化,IC 去除中间管理层,记录任何内容(潜在意思就是让 AI 可以更好理解)实现自我进化。

When the work is done by agents, the company’s coordination is between them and not just between the humans. A few things follow from that:

  • You stop being the relay between every internal communication.
  • The work has artifacts (tasks, decisions, handoffs, status files) that survive any single conversation.
  • The agents need identities and addresses so they can message each other and coordinate.
  • The agents need a shared taskboard.
  • The agents need a mechanism to learn.

Best practices for Amazon DynamoDB Global Tables – Part 1: Operational readiness
Best practices for Amazon DynamoDB Global Tables – Part 2: Failover strategies
Best practices for Amazon DynamoDB Global Tables – Part 3: Validating regional resilience with AWS Fault Injection Service

这三篇文章基本说清楚了,在 AWS 体系下如果实现 DynomoDB 的 DR 方案,包括数据同步策略 MRSC/MREC(跨区域强一致还是最终一致),如何实现问题检测和切换(Route53 ARC vs. DNS-based Route53),如何验证(利用 AWS FIS)。

结合最近工作看,AWS 实现统一的监控和切换,还是不容易的,有第三方有方案,但是没看过。

一个月Vibe Coding:我写了什么,又学到了什么

博主做了几个 Vibe Coding 的产品,给了一些不错的经验分享,在流程以及 AI 的一些局限方面,但没点到 AGENTS.md 以及 rules/changes/skills 方面的规范约束,其实说的流程方面我觉得通过 AGNETS.md 以及 changes 的规范可以解决,同时要让 AI 明白需要有来回的讨论。

之前我也看到过月刊(第34期):创造的快乐这篇,今天翻出来重新看一下,也让 AI 总结了一下 iOS App 设计开发方面的一些实践推荐,我还没真正做一个有美感的“好用” App,但我想试试,作为一个起步,我老担心技术栈方面的问题,但其实现在应该是最不应该“害怕”的问题,要的是去尝试,体会更多创造的快乐。

基于上文的推荐,我跑通了 Pencil 设计到生成代码的这条路,但是如何做更好的设计、代码和验证,结合工具和 Skills 以及最佳实践(比如:AGENTS.md)等等,需要做更多更多的事情。

中国大类资产投资 2025 年报 - SBBI

还没细看这个框架,新的知识,第一次接触 SBBI 这个概念,存下来慢慢看。

SBBI(Stocks, Bonds, Bills, and Inflation) 最早由 Roger Ibbotson 和 Rex Sinquefield 于 1976 年在美国整理发布。它第一次以系统、可验证的方式,长期跟踪股票、债券、国债和通货膨胀等基础资产类别的风险与收益。它的重要性,不只在于留下了一套长期数据,更在于帮助我们用一套分析框架来理解大类资产:不同资产在足够长的时间里,能够提供什么样的回报,又需要承担什么样的风险。

中国大类资产投资 2025 年报 - SBBI 正是沿着这一研究框架,基于中国过去 21 年的数据,对各类资产的风险与收益进行系统分解,从而回答一个基本问题:投资收益,究竟从何而来?

我们用一个公式 R=A+B-C 来拆解投资收益:投资收益(Return) = 超额收益(Alpha) + 市场收益(Beta) - 投资成本(Cost)

声明:和 AI 协作完成的,文章内容和主体是个人写的,由 AI 润色完成。

如题,文章要叙述如何在 AI 时代做架构设计,解决 what / why / how 三个问题:AI 时代的架构设计到底是什么、为什么还需要它、以及具体怎么做。

what - 什么是 AI 时代的架构设计?

先回顾传统架构设计要解决哪些问题:

  1. 方法论与体系:采用 TOGAF、C4、Arc42 等框架定义架构工作的流程与产出规范;
  2. 原则与指导标准:定义架构原则(Principles)和指导标准(Guidelines),作为决策的约束边界;
  3. 架构实施:从需求输入出发,定义系统边界,产出分层架构设计(L1~L4),同时覆盖逻辑部署与物理部署;
  4. 决策记录:遇到方案取舍时,完成 ADR(Architecture Decision Record)或 KDD(Key Design Decision),通过讨论与评审流程完成决策并归档;
  5. 协作与治理:与上下游团队持续对接,确保架构上下承接一致,并持续演进和治理。

这些活动的产出物和目的在 AI 时代没有本质变化——系统仍然需要拆解、权衡仍然需要记录、架构仍然需要治理。真正变化的是生产方式和工作流。具体来说,AI 时代新增了三个维度:

第一,产出方式从「手写」变为「人机协作」。架构师不再从空白页开始画图、写文档,而是用 prompt 驱动 LLM 生成初稿,人做审阅、修正和最终决策。比如系统上下文图(C4 Level 1)可以从需求文档自动生成初版,架构师在此基础上调整边界和职责。

第二,架构产物从「给人看」变为「人 + AI 都能消费」。传统架构文档以图形和自然语言为主,人类能读懂但 AI 难以结构化处理。AI 时代的架构产出必须是结构化文本——比如用 LikeC4 的 DSL 描述 C4 模型、用 Mermaid 描述时序——这样 AI Agent 在下游可以直接消费架构设计来生成代码骨架或校验实现一致性。

第三,架构治理从「人工评审」变为「规则 + Agent 自动校验」。架构原则不再是贴在 Wiki 上的口号,而是写成结构化规则文件,由 Agent 在每次变更时自动检查——比如「是否引入了未经批准的跨系统直接调用」「新增服务是否符合技术栈规范」。

总结:AI 时代的架构设计 = 传统架构方法论 × Architecture as Code × AI Agent 协作。核心变化不是「要不要做架构」,而是「架构以什么形态存在、由谁和什么工具来生产」。

why - 为什么还需要架构设计?

这个问题其实需要拆成两层来回答。

第一层:架构设计这个活动为什么还需要?

从需求到实现,缺少前期设计和系统模块的拆解确认,后期一定会形成技术债。这和有没有 AI 无关——AI 可以帮助你更快地写出代码,但如果系统边界没划清楚、模块职责没定义好,AI 写的代码越快,积累的技术债越深。

架构设计过程中有大量不可逆的权衡:选择单体还是微服务、同步还是异步、强一致还是最终一致——这些决策一旦做出,后期改动的成本极高。AI 可以提供方案对比和数据分析,但它无法替代人对业务上下文、组织约束和长期演进方向的判断。

此外,康威定律依然有效——系统架构会反映组织的沟通结构。跨团队的系统交互设计,本质上是组织设计问题,这不是纯技术 AI 能解决的。

第二层:架构师这个角色还需要吗?

如果从 AI Native 组织架构和 AI Builder 的视角看,专职的、只做架构文档的架构师一定没需求了。原因很简单:当 AI 能根据需求自动生成架构初稿,一个能力全面的 AI Builder(既懂业务又懂技术又能驱动 AI)自己就能完成从需求到架构到代码的闭环,中间不需要一个「翻译层」。

但这不是说架构能力不重要了,而是架构能力需要重新分布

  • 能力左移:架构师(或承担架构职责的 AI Builder)需要更靠近业务侧,具备业务分析能力,能把业务需求直接转化为架构输入,而不是等 BA 或 PM 翻译好再接手;
  • 能力右移:架构设计需要直接成为代码生成的有效输入。架构产物不再扔给开发团队自己去理解实现,而是作为 AI Agent 的上下文,驱动代码骨架、API 定义、数据库 Schema 的自动生成。

换句话说,架构师不会消失,但会融入 AI Builder 这个更大的角色中。纯「画图型」架构师被淘汰,能端到端交付的 Builder 成为主流。

新的挑战

团队协作中,如何让 Agent 输出的架构既被 AI 下游消费,又被人类团队理解和接受,是一个新的工程挑战。光有一堆结构化文件不够,还需要清晰的工作流、评审机制和质量标准。

how - 怎么做 AI 时代的架构设计?

核心理念:Architecture as Code(AaC)

选择 Architecture as Code(arch-as-code.org)作为基础范式,原因有三:

  1. 结构化文本是 AI 的最优输入:虽然现在的多模态模型能理解图片,但对于持续的演进和治理,结构化文本(DSL、Markdown、YAML)可 diff、可 review、可被 Agent 精确解析,远胜于 PPT 和白板照片;
  2. 版本控制是架构治理的基础:架构产物纳入 Git,变更历史可追溯,原则检查可自动化;
  3. AI 可直接消费并驱动下游:Agent 读取架构设计文件后,可以直接生成代码、校验实现一致性、更新文档。

工具选择

  • LikeC4:提供结构化的 C4 模型 DSL,同时支持可视化。选它的核心原因是它的 DSL 是 AI 友好的结构化文本,而生成的图是给人看的——兼顾两者。
  • Mermaid:用于时序图、流程图等动态视角的描述,同样是文本 DSL,AI 生成和修改都很方便。
  • C4 模型:作为架构分层的方法论,从 System Context(L1)到 Component(L3)再到 Code Level(L4),层级清晰,适合渐进式细化。
注:LikeC4 有标准的项目组织结构,下文的设计需要在此基础上做适配调整。

项目组织结构

整个架构项目分为两层:

  • .harness/:架构的「控制面」——规则、流程、变更记录、AI 技能定义。这是让 AI 知道「怎么做好架构」的地方;
  • architecture/:架构的「数据面」——实际的架构设计产出。这是让 AI 知道「系统长什么样」的地方。
.harness/
  rules/                              # 架构规则与约束
    kdds/                             # KDD/ADR 结构化记录
      2026-001-选择单体而非微服务.md
      2026-002-采用事件驱动解耦订单与库存.md
    architecture-principles.md        # 架构原则(如 cloud-first、单体优先等)
    architecture-guidelines.md        # 架构指导规范
      design-process.md               # 设计流程定义
      design-standard.md              # 设计标准与约束
      design-techstack.md             # 技术栈规范
  changes/                            # 基于需求输入的架构变更(参考 SDD 格式)
    _template/
      spec.md                         # 变更规格说明
      summary.md                      # 变更摘要
      tasks.md                        # 变更任务分解
  skills/                             # 自定义 AI 技能定义

architecture/
  system-context.c4                   # C4 Level 1:系统上下文
  L1-design.c4                        # 平台级设计(解耦为多个系统)
  xx-system/
    L2-design.c4                      # C4 Level 2:系统解耦为多个子系统
    xx-subsystem/
      L3-design.c4                    # C4 Level 3:子系统解耦为多个组件
      xx-component/
        L4-design.c4                  # C4 Level 4:服务/API/数据模型设计
        sequences.mermaid             # 时序图
    deployment.c4                     # 部署架构

AGENTS.md                             # AI Agent 的项目上下文(入口文件)
CLAUDE.md                             # 指向 AGENTS.md
README.md                             # 项目说明

各目录职责详解

.harness/rules/——架构的「宪法」

这个目录定义了架构的约束边界,AI Agent 在做任何架构决策时必须参考。architecture-principles.md 是最高层级的决策原则,比如:

  • 「单体优先,确有必要才拆微服务」——这是对微服务潮流的明确约束;
  • 「cloud-first,所有新服务默认上云」——消除了每个项目重新讨论部署方案的摩擦。

architecture-guidelines.md 下设三个子文件,分别定义流程(怎么做架构设计)、标准(架构产出的质量标准)、技术栈(可用技术及版本约束)。这些不是给人看的文档,而是 AI Agent 在做架构生成和校验时的规则输入

.harness/kdds/——关键决策的不可变记录

每个架构决策以独立文件记录,包含:背景、问题、考虑的方案、决策、后果。格式采用结构化 Markdown,方便 Agent 检索和应用。例如,Agent 在做新系统的技术选型时,可以检索所有 KDD 中关于「数据库选型」的决策,确保一致性。

.harness/changes/——架构变更的工程化入口

参考 SDD(Spec-Driven Development)的思路,每一次架构变更不是随意改文件,而是走「规格 → 摘要 → 任务拆解」的标准流程。_template/ 提供标准模板,每次新变更复制一份,Agent 按模板引导人类完成变更规格的填写,然后自动更新对应的架构文件。

.harness/skills/——自定义 AI 能力

存放项目特有的 AI 技能定义,比如「生成新系统的 L2 设计」「校验 L3 设计是否符合原则」等。这些技能可以被 CI 流程或开发时的 Agent 直接调用。

architecture/——架构设计的实际产出

按 C4 模型的层级组织:system-context.c4 描述系统与外部参与者的关系(L1),向下逐级细化到组件级(L3)和代码级(L4)。每个 .c4 文件是 LikeC4 DSL 结构化文本,.mermaid 文件是 Mermaid DSL。两个格式都是纯文本,可 diff、可被 Agent 精确读写。

AGENTS.mdCLAUDE.md

AGENTS.md 是整个项目的 AI 入口上下文文件,告诉 AI Agent 这个项目的性质(架构设计项目)、目录结构、工作方式。CLAUDE.md 是一个符号链接或引用文件,指向 AGENTS.md,确保不同 AI 工具都能找到项目上下文。

工作流示例

以「需要给订单系统设计异步通知能力」为例,走一遍完整流程:

  1. 发起变更:开发者复制 .harness/changes/_template/,填写 spec.md(描述业务需求:订单状态变更时通知下游)、summary.md(变更范围:新增消息队列,订单服务作为生产者)、tasks.md(拆解为 3 个任务:选型 MQ、定义消息格式、更新 C4 设计);
  2. AI 生成架构初稿:Agent 读取 spec.md.harness/rules/(原则、技术栈规范),生成 L3-design.c4 的变更和一个 sequences.mermaid 时序图初稿。技术栈规范约束了 MQ 只能选 Kafka,Agent 自动遵循;
  3. 人工评审:架构师(或 Team Lead)review Agent 的产出,调整系统边界——比如决定通知服务是否需要独立的子系统还是作为订单系统的扩展组件;
  4. 记录决策:如果讨论中有取舍(比如「为什么不直接调 API 而要走消息队列」),用 KDD 模板记录决策,归档到 .harness/kdds/
  5. Agent 校验 + 驱动代码:CI 流程中,Agent 校验变更后的 .c4 文件是否符合 architecture-principles.md,然后基于 L3/L4 设计生成 Kafka topic 配置、消息 Schema 和生产者/消费者的代码骨架;
  6. 合入并演进:变更合入主分支,架构资产随代码一起版本化管理,后续任何人对架构有疑问,直接读 .c4 文件,不需要翻 Confluence 或过期的 Wiki。

ADR/KDD 模板示例

# KDD-2026-003:订单状态变更通知采用消息队列而非同步 API 调用

## 背景
订单服务完成状态变更后,需要通知下游(库存、物流、通知中心)。
当前方案是同步 HTTP 调用,下游增多后订单服务耦合严重。

## 决策
采用 Kafka 作为消息中间件,订单服务发布事件,下游各自消费。

## 考虑的方案
| 方案 | 优点 | 缺点 |
|------|------|------|
| 同步 HTTP | 实现简单,可立即获得结果 | 耦合重,下游故障影响上游 |
| Kafka 消息 | 解耦,下游可独立演进 | 引入 MQ 运维复杂度,需处理最终一致性 |
| gRPC Stream | 性能好 | 下游改造大,团队不熟悉 |

## 后果
- 订单服务不再感知下游数量变化
- 需新增 Kafka 集群运维(已在技术栈白名单中)
- 业务流程从同步变为异步,需调整监控和告警策略

常见反模式与风险

  1. AI 生成的架构直接合入不加评审:AI 不了解组织的政治边界和团队的隐性约束,可能产出技术上合理但组织上不可行的方案。每次 AI 产出必须经过人工 review。
  2. 原则写得太大太空,Agent 无法执行:像「系统应该可扩展」这种原则对 AI 来说是噪音。原则必须具体到可被程序化检查——比如「系统间通信只能通过 API Gateway 或 Kafka,禁止直连数据库」。
  3. 过度依赖可视化,忽略结构化源文件:如果团队直接改图而不改 DSL 源文件,架构就退化成了传统的「画图存档」。必须坚持 DSL 是唯一真相源(Single Source of Truth),图只是渲染视图。
  4. KDD 写了不维护:过期的 KDD 比没有 KDD 更危险——Agent 检索到旧决策可能做出错误约束。KDD 应该有生命周期管理,定期 review 和标记废弃。

成功度量

当以下现象出现时,说明 AI 时代的架构设计实践已经落地:

  • 新系统的 L1~L3 设计初稿由 AI 生成,人工只做 review 和微调,耗时从天级降到小时级;
  • 架构原则变更后,Agent 能自动扫描所有现有设计,列出不符合新原则的条目;
  • 新人加入团队,通过读 .harness/rules/ 和 AGENTS.md 就能理解架构约束,不需要老员工口口相传;
  • 代码实现与架构设计的偏差能被 CI 自动检测——比如代码中出现了架构设计里没有定义的服务间调用。

总结

AI 时代的架构设计不是要抛弃过去的方法论,而是把架构从「人写的文档」变成「人 + AI 协作的结构化资产」。核心三件事:用 Architecture as Code 让架构产物可机器消费、用规则文件让约束可自动执行、用 AI Agent 让生产和校验自动化。架构师这个头衔可能会淡化,但架构能力——拆解系统、权衡取舍、定义边界——永远需要,只是承载方式和协作模式变了。

本周过的有点浑浑噩噩,回顾失去了主线和忙的方向和核心内容,下周开始调整一下。

本周观影

  • 在北极独自划船30公里去无人小岛露营:挪威博主又有更新了,海钓和岛上露营,海鸥、海豹和各种其他鸟类作伴,路亚小艇和各种装备,好玩又好看,真羡慕啊,最后总算钓上了几个螃蟹,酷!
  • 在 B 站的 Up 主行者况露看 EBC 大环线的徒步 vlog,成熟的路线,雪山盛宴,景美人美,我想去走走但是一想到要坐飞机那么远(我怕颠簸和对于失重超级敏感),又是犹豫了,看机缘吧,也许念念不忘会有点回响。(周四又正好看到了这个文章 天高地厚之间的行走:EBC 三垭口 + Gokyo + 岛峰全记录,作者也是户外达人了)。
  • 【阿丙】云南这座小城,温柔得让人想要住下来|云南 玉溪:云南玉溪,没去过,小城,洒满阳光,云南总是那么吸引人,去年去自驾了两周想着就是以后有时间多去普洱那样的地方住住,这个 Up 主还有云南其他好几个地方的视屏,非常好,也还有长江三峡好几个地方的 vlog,推荐。
  • 张雪为什么又又又又赢了?:认真踏实勤恳,异常优异的供应链和制造,会赢无数次。
  • 《风味人间 1 - 3 滚滚红尘》(还没看完):云南稻草烤猪,新疆烤鱼,远古流传下来的吃法;摩洛哥的塔吉锅,山东滕州的铁锅。

本周阅读

  • 《金融怪杰》:这两天读的这个人 - 布莱恩·吉尔伯,有一点记忆非常深刻,关于自我认知管理和情绪管理,了解自己和控制情绪,另外话说就是知道自己的能力边界和能力圈,同时懂得控制情绪,还在继续阅读中。

本周播客

“自由现金流”
“最后得出的一个结论是,价值投资在不同的市场都是有效的。大家往往对价值投资的理解是我持有的时间足够的长,它就是价值投资。实际上不是的,是你持有的资产,这些资产在远期能够稳定的创造现金流,并且你能够以一个合理或者合理偏低的对价去买到这个资产。长期持有,这个相对来说是价值投资。”

本周胡思乱想

  • 投资方面,看准了一定要舍得下重手,不然真是没有大幅“盈利”早日自由的可能的,但一定是不亏钱是第一要务,这方面所以要学习卡拉曼的《安全边际》。
  • AI 时代如何做架构设计文里,项目结构和实际执行起来要考虑如何结合 SDLC,而不是架构脱离后续的研发独立存在。
  • 看一下我们有的痛点,如何通过 AI/LLM 可以解决?

    • 架构设计遵循我们的 Principles、Patterns 和 KDDs
    • 架构设计的 review,包括文字和 lucid 图
    • Threat Modelling 执行
    • 架构设计的治理,确保实现符合架构设计
    • 实现的 reverse engineering,探视是否符合架构设计,如果之前没做过
  • 提醒一下自己,投资方面投入有点过于多了,用力过猛反而得不偿失了。
  • 团队沟通一片混乱,奔溃。

本周投资

  • 最大的问题是政策的不确定性,周五大暴击,周末有了一些准备的动作
  • 继续买入了点 SaaS
  • 集思录上看到了现金管理(https://www.jisilu.cn/data/repo/)这个栏目,学习了一下如何操作,学习了一种新的投资方式(国债逆回购,资金短期借出以获取固定利息的低风险理财方式,卖出 GC 开头的国债),后续有空闲的资金考虑操作一下

本周文章

这周我文章看的有点少,如上面说的投资方面用力过猛了,得收回点。

Forward Deployed Engineer:AI 时代的新宠岗位,到底干什么?

了解一下 FDE 这个角色,其实做 tob 服务,过去 onsite 在客户办公室,从来都是这样的,只是现在对于这个角色赋予更多的字面意义和光环,其实本质和 tob 服务过去做的事情没有啥本质区别。