记录时间：2026-07-27 14:26:07

本文按用户提供的 PDF《梁文锋投资者交流会-手机阅读版》全文排版发布，正文内容未作改写。

录音：5月20日

整理：2026-07-16

重新排版：2026-07-23

音频《deepseek 0520.m4a》，总时长约 3 小时 44 分钟。本稿由语音识别自动转写并经 AI 整理，未区分说话人；时间戳为音频位置。个别专有名词与数字可能存在识别误差，请以原录音为准。

00:00:01

以及我们公司的其他同事，我们一开始来做这个公司，初衷是没有想到说我最后要赚多少钱，要到资本市场上去，要上市，要怎么样的，所以我们是没有这个初衷的。最开始的几十个人完全没有这么想过。如果他这么想，他就不会来。所以总体讲，我们是怀着一个对这个世界非常大的善意来做这个事情，然后我们觉得这是对人类有用的，这是一个金钱以外的事情。当然，到了后面，这个事情发现利益非常大之后，又有其他的诱惑，这个是另外的事情。但是我们出发的初衷、我们的愿景，以及我们保持到现在的这个愿景，不是按照一个商业利益最大化的方式来做的。我觉得这点比较关键。我大概二十年前的时候，在管理上我最崇拜的是杰克·韦尔奇，就是 GE 的前 CEO。现在回来看，他说的大部分东西可能都已经不对了，但是他最重要的一点说对了：一个公司最重要的是它的愿景。管理一个大公司，靠的不是你的规章制度，靠的是愿景。愿景是什么呢？愿景不是挂在墙上的标语，愿景是你怎么做，不是怎么说，就是你怎么实际运行。反正杰克·韦尔奇说的原话我忘了，大概是这个意思。所以，我们是怎么管理这么多人、怎么组织起来的？其实我们没有组织，就是愿景驱动的，靠一个愿景来组织。我们是没有组织的。这个有好处，也有坏处。未来我们会想办法扬长避短，但这个是我们的特色。我们并不是以一个“我要实现什么 KPI、没有考核”的方式来做，只有愿景。这个愿景甚至也不是成文的，并不是写出来的，没有写出来过任何东西。这个愿景是在我们做事情的方法、我们对待这个世界的态度里。可能我们公司每个人对这个愿景的理解也不一样，可能每一个人的愿景也是有差别的，但是在一个大的方向上是一致的。

我觉得还是怀着对这个世界非常大的善意，然后想做一点事情。我们是用这个来组织起来的。接下来我先讲，讲完之后大家再提问。我可能会围绕着这个愿景来讲后面的事情。这个愿景是真的，不是编出来的，我们是真的这么想，真的这么做的。否则你没法解释我们的很多事情。这个愿景为什么我们这么坚持开源？因为这个愿景本身就要求开源。你没有这个愿景，你没法把人组织起来。比如说，智谱也开源，但是智谱的开源跟我们的开源不一样。智谱的开源有一种被迫的感觉，他们觉得这不是本意，但是对我们来讲，这就是我们的本意。然后在开源这个事情上面，我们一开始就想得非常清楚。首先，第一个就是愿景；第二个，我们认为要把 AI 这个事情在商业上做成，开源是有好处的。这听起来有点矛盾，有点违反直觉，因为在历史上，开源跟商业化都是有冲突的。但我觉得 AI 跟以前不一样。因为在历史上，一个软件公司，它的市场一年可能就几十亿美金，离开源了，它就没有了，可能就只剩下几千万或几亿美金了。但是 AI 这个事情足够大，最终它可能得占掉人类社会 GDP 的百分之十，比如说。那么它其实是一个非常大的数字。一个人独占这个事情，你不可能独占这个事情，你一定得跟别人分享，否则你肯定活不下来。这跟之前开源做一个软件可能是不一样的，因为那个软件的市场就没那么大。但是 AI 这个事情实在太大了。如果说我们想独占这个利益，那么一定是要被历史抛弃的。我觉得最主要这是一个客观的规律，这是一个历史观。并不是说我不开源，我就能够独占这个市场，这在理论上就不符合客观事实。你一定会遇到很多阻力，一定会有其他的方法阻止你实现这个目标。在这种情况下，我觉得不一定要按照传统的商业思维。你需要有一套机制来确保你自己能够获得的利益是有限的，那么你才有可能做成。需要克制，我觉得是需要克制。如果说我们想在我们手上把 AI 这个事情做成，首先第一个，我觉得是需要克制的。不能够想着人类 GDP 的百分之多少都归我了，或者说中国 GDP 百分之多少都归我了。你越这么想，越做不成。所以我们从一开始就觉得需要克制。你越克制，你越有可能能够做成这层事。这是一个商业上的考量，当然这是一个宏观的考虑。我觉得这是符合直觉的，至少是符合我的直觉，或者说至少我是真的这么想的。我们并没有非常多的其他优势，我们没有什么本事，我们并没有比别人有钱，也没有说我们人员比其他公司更好，其实没有的。你想，我们两年前成立这个公司的时候，我们又没有很多钱，又没有很多卡，又没有什么知名度，又没有什么号召力，我们就是一群非常平凡的人。

00:11:49

我真的就是一群平凡的人。如果说喜欢的一个叙事是一群平凡的人做出了不平凡的事情，而不是一群天才做出了不平凡的事情，这个跟我们的克制是很有关系的，跟我们的克制、跟我们的愿景是一脉相承的。那么，开源跟商业化会不会有冲突？我觉得在 AI 这个事情上面，你不克制，你就不起。开源是属于克制的一部分，那么我们的克制不仅表现在开源上面，我们还表现在很多方面上。但总体上来讲，我们是不用考虑开源这个事，不用考虑克制这个事情。你越克制，可能就越容易做成，或者说至少到目前为止是印证的，到目前为止是能解释得通的。否则没有办法能够解释为什么我们能够做成：我们并没有什么武器，起点又非常低，资源又非常少，我们的人其实也就是随机的一群平凡的人。我自己也就是一个大学毕业的学生，也不是最顶级的那个学校毕业的。这个克制也是我们愿景里的一部分。AI 这个事情太大了，利益太大了。我们非常克制，只要能够做成，最后利益都会非常大。你随便分一点，利益就非常大，所以现在根本不用考虑拿这里面的哪一部分利益、怎么拿，我觉得根本不用考虑这件事情，因为这个利益足够大了。你只要分一点点，就已经很足够了。所以我们之前说，我们只赚取一个合理的利润，只看你的意愿，而不是利润之大，这个是不一样的。这不是我们的 API 定价。我们 API 定价觉得一个合理的利润，大概是我们到市场上买一批设备回来，十个月收回成本，我觉得这是一个合理的利润。在当前的情况下，考虑到你有风险、还有前期的投入等等，如果一个服务器我们在财务上按照三年或者五年的摊销，但在商业上，我们觉得大概十个月收回成本，我们觉得够了，OK，我们觉得够了。所以这个是我们现在 API 定价的逻辑。我们的 V3.2 Flash 跟其他的，都是十个月收回设备的成本。这就是我们的标准。它其实不是利润最大化的，如果利润最大化，应该把价格设得更高。因为在这个价格区间，用户的需求是没有弹性的，就是我价格再翻一半，或者说我价格再抬高一倍，token 的消耗量区别不大的。如果我价格再贵一倍，我的总收入接近一倍。稍等一下，我对一下。哎呀，太好了。我跟你们讲个故事，就是我们那个 DDCP，是我们那个模型。一开始我们担心需求太多，所以一开始把价格定得比较高，团队里大家不是很高兴。后来我把价格又降下来了，降到四分之一，大家就很开心。我觉得这个才是我们真实的想法。就是我前面说的愿景，我们还是让这个东西对人是有用的，而不是我们赚最多的钱，而是我们在能够赚到合理利润的情况下，大家都用得起。我觉得这次我们公司其他人的想法，就是我们那时候降价的时候，公司群里面很多人是欢呼的，大家都觉得很开心。因为这是我们花了这么多精力，这么用心把这个模型做好的目的。目的就是能够非常便宜、效果非常好，能够让大家都能够充分地用。我们就觉得这很开心，这是我们的动力，这是我们的愿景，这是我们公司能够凝聚到一起去做这个事情的共识吧，这是我们公司内部的共识。这点应该是比较特殊的，因为降价这样对于我们其他的竞争对手来讲，肯定不是个好事，他们一定不是欢呼的。因为你的收入、你的 ARR，那个你降一半，ARR 就掉一半。对，这是一个我们不一样的地方。我们觉得这就够了。从我们公司内部来讲，我十个月收回成本，这个商业上我已经非常满意了。对于公司外部来讲，我们也觉得这个价格是大家比较开心、比较乐意看到的，大家是双赢的，公司跟社会、跟所有人都双赢的。我觉得，OK，刚刚有人在屏幕上留言说，十个月回本这个利润太高了。确实是还有降价的空间，确实还有降价空间。在模型的优化上也还有空间，所以整体降价空间还是比较大的。但是这个成本，十个月回本，我们自己能做到，其他家做不到。像可能阿里或者腾讯，他不是我们的优化，他的成本应该是要比这个高好几倍的。这里还是有很多优化的工作。刚刚说我们为什么不继续降价，是因为它没有弹性。就是我再降价，需求不会更多了，或者我再降价，需求增加得很少了。因为这个价格所有人都用得起了，大家都觉得这个价格是满意的，不会因为这个价格贵而不用了。

所以降价首先公司不会有更多的收入，对社会来讲也没有更多的价值，因为这个价格大家都满意了。你价格再低，对这个社会的幸福感也没有增加很多。对，OK，不过刚刚这个问题上，就是我们在定价这个事情上面，我们肯定不是以

00:25:32

公司收入最高或者利润最高，不是最出发点的。这是我们克制的一部分，因为从短期来讲，你价格高一点，你可能收入多一点；但从长期来讲，还真不好说。因为我觉得克制是一种策略。对我来讲，克制是一种战略。就在于有时候你可以舍弃一些，来换更多其他的东西。不开源这个事，其实也是一样的，也可以认为是我们的压力，也可以认为是我们的让利。首先，这个让利对于我们公司内部来讲，我们很高兴，大家都很开心，员工觉得很有成就感，我们会因此有凝聚力。以及这个让利对社会是有好处的，社会也很高兴，其他同行或者说普通人都会很高兴。所以这种克制，我理解是这种克制从长远上来讲，能够增加我们做成 AGI 的概率。在考虑一件事的时候，我是毫不怀疑 AGI 会有非常大的商业价值。那么在这个基础上，我优先考虑的不是我怎么多加一点份额，我怎么多拿一些份额，我优先考虑的是我怎么增加我能够做成的概率。这个克制可能还体现在很多其他的方面。比如说，我们去年春节用户突然很多，但是我们并没有去追求我要留这些用户，或者说拿这些用户来变现，或者说我要去抢这些商业利益，在用户上面兑现。我们没有去抢用户，没有去赚钱，但我们很努力想办法把用户服务好。我们并不会有这样的想法，说我要做成下一个超级 App，然后我要去跟谁竞争，我要做成下一个字节、做成下一个腾讯，完全没有这样的想法。我们是可以这么做，但是我们没有这么做。我的理解是，这也是克制的一部分。你不要想什么都要赚了，你好像有了用户之后，好像就能够做成下一个字节了，然后你就把那个吃了。我觉得这个在商业上是行得通的，是有可能的。如果去年时候我们用了大笔钱，就跟字节去抢用户，也是一种打法。但是我们选择是一种非常克制的做法，就是我不跟你去争这个东西，因为后面还有西瓜，前面的可能都是芝麻。

我不应该什么芝麻都抢了。当然，可能这个芝麻比较大，但我觉得后面的 AI 可能前面都不算大。现在来看，去年我们没有在 C 端去发力，可能是对的。因为能看到后面真的是有更大的西瓜，前面真的只是一些小芝麻。如果去年我就有很多钱，然后把这个事情做得非常大的话，有什么好处？你并没有得到什么东西。这些是我的真实想法，因为我觉得后面的 AGI 机会应该是非常大的，后面的AGI 机会永远是非常大的。我甚至不用考虑我到时候在里面是占一个位置，或者说在那里面我的商业模式是什么，我们根本就不用考虑。只要有那么大的商业机会，你一定是有办法的。那么前面的芝麻，我们也会捡，但是我们就随手捡一点，并不会说我停下来，或者说我把它当成重要事情来做。所以去年的 C 端日活这些，我觉得可能就是个小事。但我们也捡了，我们也用一个比较低的成本维持了用户的使用，因为有可能以后是有用的。虽然现在不知道这用户有什么用，现在它是一个纯成本的支出，但是以后可能是有用的。既然是随手能够拿到的，我们就会顺手拿到。包括今年来看，很有可能我们在 API 或者 AI 方面的 ARR 收入，也是有一个机会的。就是如果这个需求可以继续扩大，如果继续扩大，显卡可以买到更多的显卡，那么 ARR 做到几个亿美金是很有可能的。如果说 AI 能做到十亿美金的话，那么基本上我公司的现金流可能就能够回正了，能够cover 我的研发费用，能够 cover 我的所有费用。所以说这个也是有可能的，但是我们没有把它当一个优先来做。这个我们会做，但我觉得这个是个重要事情。它不是我们第一优先考虑的，或者不是我们今天真的关心的。更大的机会应该还在后面，前面的机会包括去年的 C 端、今年的 B端，我觉得这事要做，要把它做好，但这不是我们的目标。或者说，我们公司大部分人不认为这是一个非常重要的事情，不认为这是一个跟 AGI 比较起来同等重要的问题。开源那个可以多说一下，因为之前有很多问题问的都是开源。首先，我觉得我们是会开源的，然后我们最强的模型可能也是会开源的。因为我看不到闭源什么好处，看不到必然的好处。字节它的模型是闭源的，它有什么好处？我看不到有什么好处。哪怕是模型开源，你把所有东西都告诉别人，这个门槛也非常高。别人要用起来，这个门槛也非常高。他要用起来，就很难；其次，他要用起来，还要成本做得很低，也很难很难，没有那么容易。

并不是我开源了，他就能够轻易地做到跟我一样的部署成本。这里边还是有很多工作要做的。虽然说这些工作原理都明白，但是不是每一家公司都愿意，或者都有这个意愿和能力来组织人力去达到这个目标的。这点我也很习惯。它可能就不擅长做这个事情，因为它阻力太大了。它要控制这个成本很难，它有很多管理上的以及物理上的制约。这也是创业公司的优势，因为创业公司如果太小的话，你没有这个力量来做这个事情；如果你是大公司的话，你很难组织。

00:38:36

这个事情都有难点，所以这是属于我们这个规模的公司的一个甜区，sweet point。然后如果我们更大了，可能我们没有其他问题；如果更小的话，朋友们力量又会不足。所以，至于开源，我觉得我们应该定价。目前我们应该认识到，不会逼人。因为定价的模型，我也不会收一个非常高的费用，我也是可能按照十个月回本来收这个费。按十个月回本，就已经能够把竞争对手……我按十个月回本这个，就能够让独立部署的第三方无利可图。第三方他做不到，他做不到这个成本，他肯定做不到。所以开源并不会影响我的收入。当然，如果说我要赚一百倍的利润，那么开源是……听到你的话，但视频好像掉了，老板。刚刚可能是电话接来了。就是开源，我觉得对我们的商业模式是没有任何影响的。前提是我们只赚六倍的利润，十个月收回成本，大概对应的是六倍的利润。我们只赚六倍利润的情况下，开源是不会有什么影响的。但如果说你要赚一百倍利润，那么开源确实会影响你赚一百倍利润，因为第三方会部署，他可能是二十倍成本，就比你低了。这个模式是不是长期可以持续的？我觉得是可以的。就在我们这个愿景下，我觉得开源是长期可以持续的，或者我们是打算这么做的。你可以认为，就是有克制，也是有让你比较长利。这个策略是能够在技术前面让我们有更多的机会，我们能够做成 AGI 的概率也是更大的。我们更从容。

你想，我们根本都不用加班，因为就没那么难。但是对其他家来讲，可能就很难，因为你想的也太多了。其实不难的，根本就不难。才开始是一个……外面可能看起来，我们选了一个很难的模式，我们要做研究，我们去做最难的事情，好像是个 hard 的模式。但其实我们在外地方舍弃了很多，使得我们还是非常有力的，我们还是做得非常轻松的。所以对开源这件事情，实际上我的判断是，它是持续的。开源和商业付费之间没有冲突，前提是六倍利润的情况下没有冲突的。六倍利润看起来很高，但其实不高。因为现在 AI 的效率这么高的情况下，现在一个合理利润可能就是这么多。未来它可能会降到，比如说四倍、三倍，我觉得这已经是……再到底也不可能再降了。但就是它还是会有很大的利润。就光是看卖 API 这个事情，但我并不觉得卖 API 这个事情有那么大吸引力。但是就这个事情，你可以说明，没有，我没有看到有什么冲突。然后我也不担心别人部署我们的模型，然后跟我们来竞争，一点都不担心。我们还希望他们能够部署起来。我们尽可能给开源社区提供帮助，协助大家能够把我们的模型部署起来。我不担心他会跟我抢这个生意，因为这个市场足够大。我只担心他部署不起来，他有些细节没做对，效果变得比较差，或者说他的成本会比较高。对，这里是没有冲突的。然后去年的时候，我问的，去年有 To B 这个生意的时候会问得比较多的是：我们那个 C 端，我开源，那么 C 端是不是跟我这个 C 端又会冲突了呢？因为我没有流量的优势，或者说腾讯自己流量很多，他部署我们的开源模型，他就把所有的 C 端用户都接过去了，就把我的 C 端用户都抢走了。但其实并不会，这个还是有很多原因的。然后问题是：我们给的开源模型，跟我们自己部署的模型是不是一样？是一样的。我们不会说开源一个差点的模型，然后我们自己部署的时候用一个更好的模型，是不会的，是一样的。这也说明它其实没有冲突。我们去年一整年，在 C 端我基本就是开源了，然后 C 端的服务没有看到冲突，真的没有看到冲突。所以，这是开源的这部分。

然后下面还有就是，公司的长期 vision，我觉得我们目标应该是 AGI。每个人对 AI 定义不一定一样，但是不妨碍我们把 AGI 当做我们的目标。从技术路线上来看，其实 AGI 这条路线图是比较清晰的。跟目前的这一代 AI 技术，如果说你能够把一个问题描述得很清楚，给它完整的上下文和指令，它已经超过人类了。但这里有个定义，有个前提是：你给它完整的上下文，你给它完整的指令。然后这个定义是很难达到的。比如说我们今天开会，其实我们前面有很长很强的上下文，可能大家有几十年的上下文，然后这是 AI 不具备的。那么现在 AI 能具备的是，在一个局限的上下文里面，它能做得比人更好。但它还是替代不了人类。这里面还差一个地方，是持续学习。因为人也能够持续学习。你招一个员工，他可能花两个月时间来熟悉这公司的环境，熟悉他的工作，他谈两个月的，你这样他就可以上手了。他就能做很多事情。他能够听懂你说的话，比如说你说，叫那个小王来，他就知道小王是谁。但如果 AI 的话，因为这个上下文，他前面没有这两个月的学习。你跟他说，叫小王过来，你得告诉他小王是谁、什么职务、他在哪里、要怎么去找他、要找他的时候注意什么。你得给 AI 所有的上下文。那么在这种情况下，AI 是能做的，但是你不可能给他所有的上下文，也不现实。所以 AI 并不能够替代你的员工。但如果说 AI 具有持续学习的能力，它跟你的员工一样，到公司学习两个月，那么

00:51:02

但就可以替代天下的人了，所以我们离下一步还差一个学习去学习。AI 的发展，我们可以理解成它是一个阶梯。去年走的阶梯是 CoT，就是思维链。因为我们发现，通过思维链的方式，可以让智能达到一个更高的水平。通过它自己思考，可以让这个上限，可以让这个 AI 能做更多的事情。那么我们又跨过了一个阶梯。今年的阶梯就是 Agent，因为我们发现，用 Agent 的方式，即便多有事情也可以做，它的能力范围会更大，它的智能上限会更高。为什么是阶梯呢？因为后面的每一步都是基于前面的基础上的。Agent 要用到 CoT，然后CoT 也要用到前面的阶梯，前面的阶梯就是语言模型，所以它并没有一步是白走的。所以，AI 的发展，智能的走向是有迹可循的。说今年走的这个阶梯是 Agent，但是 Agent这个阶梯，它也是会走完的。就是它把所有可能解决的问题都解决完之后，但是它还是不能替代你的员工，但是它已经到它能力的上限了。就好像 CoT 一样，CoT 到它的上限之后，它已经超过最顶尖的人类了，在做奥数题、写程序上面已经超过最顶尖的人类了。但是它还是停在那个地方，它那个技术并没有能够到达 AGI。所以你看，AI 这个智能的走向，它是有迹可循的。然后在 Agent 之后，我们觉得应该要解决的问题是持续学习，就是怎么让模型可以持续地学习，而不是说你要给它一个很强的训练，它应该能够像人一样做一个比较长时间的持续学习。这个问题跟完成任务等等是同一回事，它们相关，解决的是同一个问题。我们现在站在Agent 这个地方，能看到的是下一个瓶颈，就是持续学习。下一个要解决的问题，就是解决怎么持续学习，这个是看得到的，是相对来讲比较明确的。就是卡在前面的这个障碍，你必须要跨过去，而且一定是有办法能跨过去的，但需要时间。持续学习之后，可能我们就会来到一个奇点。这个奇点就是，当这个模型能够持续学习之后，它已经能够做人类能做的所有事情了。它就能够自己开发自己的版本，能够自己再研究，然后开发自己的下一个版本，开发更前的人工智能模型。所以它就会到一个奇点，能够实现自己的迭代。但这个奇点，它并不是一个奇点，它也是一个渐进的过程。这个过程可能也是一个比较长的渐变，它不是个突变。但是习惯性地，我们都认为它可能是个奇点。因为在很早之前，那些预言家认为这里会有个奇点，但其实它不是一个奇点，它是一个连续的过程。然后这一步走完之后，我觉得才是具身智能。这是我们的推测，这是我们觉得这个时间表应该是：先解决学习去学习，然后再到那个智能的奇点，能自我迭代的奇点，然后才是具身智能。到具身智能之后，它就走进现实世界，可以给你做家务，可以给你养老。我们觉得这是一个比较理想的路线图，但每个人的观点不一样，没有对错之分。只是我们觉得，这个路线图是最轻松的。这个路线图是因为每一步你要做新的都很少。这个路线图我们可以不用加班。但是如果路线图是反过来的，比如说它要先实现具身智能，那么这里自己做得很累，这是一个很苦的活。我们不希望是这样的路线图，我们希望做得轻松一点。

如果说我们先解决持续学习，再解决那个自我迭代的奇点，再解决具身智能，这个路上就很轻松。因为到后面之后，你可以用前面的技术来帮助开发后面的技术。奇点之后再做具身智能，那个就不用人来做，就不用我们来做了，那个模型自己就可以出来了。所以这个是回答我们的长期目标是什么。我就跟他说，这就是我们的长期目标，就是我们说的 AGI。大家回到现实。去年最重要的现实就是，大家都要做 Chatbot，要抢 C 端的流量。那么今年的现实是，大家都要抢 To B 的收入，要参与到这里面去，因为如果不参与的话，根本就不在牌桌上，对不对？但我们并不认为它是一个重要事情，或者说，在我们公司内部，我们真正关心的，其实是刚刚我说的这些 AGI 的路线图，以及下一步这个技术怎么突破。但是有一点很奇怪的是，最想得到的东西，反而你就得不到。那个并没有那么在意的事情，反而是还蛮容易能够得到。这里边有一个战略上的优势，就是我们心里面想着 AGI，我们做的是 AGI。那我们再做那个应用，再做那个 C 端、B 端的时候，根本就不用太多的心思去做那个事情，其实花很少的精力就可以了。我觉得是说，你站在一个技术的高位上来做相对低一级别的技术，是有这样降维打击的。至少在去年的 C 端，我们看到确实是这样。我们没有在 C 端上花很多力气，甚至一度我们都不想维护那些用户了，但是用户赶都赶不走。因为真的是赶不走，所以最终都还在。但稍微……然后今年 B 端的这个收入，现在看起来这个增长还比较乐观。我觉得可能这个数字跟同行比的话，应该也是比较好的，我估计。但是我们并没有花很大的精力去做这事情，我们根本就没有

01:02:45

做一件事情，就是顺便做的。做互联网智能的上线，走的时候，AGI 这一步是我必须走的，是个台阶。通往 AGI 的路上，我要经过这个台阶。那么我把这些技术都通过 API 给大家服务，我没有干额外的事情。我们还是在做 AI，这是一个副产品。我只要搞几个人维护这个 API 就可以了，甚至客服都没有，也不用销售，什么都不需要，用户自己就会来。

或者说，被认为是 C 端的用户，C 端和 B 端，都是我们做 AGI 路上的副产物，都是一个中间的产出，跟我做 AGI 没有冲突。我并不是为了做 C 端，或者为了做 B 端而去做它，而是我们做 AGI 是为了做 AGI，刚好能产出这个东西，我就把它拿来做商业化了。这跟其他公司不一样。其他公司就是为了做这个，为了服务 C 端用户，或者服务 B 端用户而去做这个模型。但对我们来讲，初衷不是这样的，我们初衷还是去追求 AGI。我觉得这个在一定程度上是一种降维打击。AGI 是更大的愿景，这个愿景能够凝聚起更多优秀的人，它有更强的凝聚力。所以我在组织上有优势，然后我利用这个优势去……它就是一种降维打击。但如果你是一个商业公司，你的愿景就是服务好 C 端用户，那么是另外一个故事。他有其他的优势，在产品上、用户服务上、流量上会有优势，但是在技术上没有优势。现在比较有利的形势是，模型技术是最重要的。你要将模型做好，其他……对，然后这个可以解释我们之前发展的轨迹。我们真的是选择 AGI，然后我根本没有想着说要做很多的用户。去年春节我们突然火的时候，那不在我们的剧本里面，我们完全没有想过那个东西。我们就是想把这个技术做好。但是那时候我发现，其实我们这个组织相对于完全商业化、以产品为目标的组织来讲，在人才跟组织上是有额外优势的。这也很神奇。那时候 C 端大家都抢得头破血流，结果被一个没有去抢的人牵走了。这个也确实说明我前面说的逻辑是有道理的，确实是有人才和组织上的优势。这个人才优势不是说我的人比他更聪明，而是这些人才我怎么组织起来，怎么激励他，然后怎么合作。这个东西是有优势的。因为你把聪明的人聚在一起，并不是说他自然而然就能够合作，自然而然就能够非常有激情地去奔一个目标、去完成的，所以你需要一个愿景。我们前面的经历给我的启示是，AGI 这个愿景是很强大的。OK，这是问题。然后下一个问题是，核心利益的重要性是什么？我前面说，我们在很多方面都要非常克制。但是我们的核心利益是什么？其实我们的核心利益只有一点：我们最大的核心利益是要保持团队的稳定性。这是我们最大的核心利益，甚至可以认为是唯一的核心利益。

只要我能够保持团队的稳定性，我一定能做成，一定能做成 AGI，就这么简单。只要大家都不走，我们能够继续做，我就一定能……基本上没有什么风险。只是说早点晚一点，将遇到挫折；如果遇到挫折，大家都不走，那么我又可以继续。钱肯定不是问题，资源不是问题，其他要素都是容易获得的。对我们来讲，只有一个核心利益，只有一个没法退让的：我们必须要保持团队的稳定性。这也是我们面临的一个非常大的挑战，或者说，我觉得是最大的风险。当然，这个风险随着我们近期的这一次融资，得到了比较大的解除。因为大家拿到的期权都还是比较多的，金额还是比较大的。从团队稳定性来讲，只要最重要的一些员工、最老的员工能够稳定，那么其他人是不太会走的。其他人哪怕期权少一点、收入少一点，他也不会走。因为他不是全奔着钱来的，大家都希望在一个能够做成 AGI 的环境里面去做这个事情。所以对人才来讲，还是有吸引力的。从历史上来看，我们的人才流动是比较少的，跟同行比，我们人才流动永远是比较少的。但是，这依然是我们最大的挑战，是唯一的挑战，可以这么讲。其他都是时间问题，其他最多导致我们晚半年、晚一年，但是不会说做不出来。肯定是不缺钱，肯定是不缺资源，其实这些都是不缺的。所以我们现在做的很多事情，都是为了保持团队的稳定性。除了这一点以外，其他我觉得我们都是可以不要的，都是可以克制的。我们一直非常克制，不愿意跟任何一家互联网大厂或者小厂成为对手。我希望我能够给他赋能，或者希望我能够协助大家去做这个事情，希望能够帮助大家做这个事情。这也是我们前面说的，我们的商业意义的一部分。前提是大家不要管……

01:15:12

在这个前提下，我们是很愿意协助、帮助任何人，甚至我们的竞争对手，包括阿里、智谱、月之暗面，去做得更好。因为我们并不损失什么东西，我们本来也是开源的，开源也是没有把边界尽可能说清楚，对怎么做，希望你能够复现；你如果复现不了，你讲，我告诉你怎么复现。这本来就是开源的一部分，不会因为你是竞争对手就怎么样。当然，如果是合作伙伴，我会做更多的事情。但是在大的利益上面是没有冲突的。在对外面打交道的时候，我们的态度是：我们只做 AGI 的主线。这就是我刚刚说的这个GPT、CoT、Agent 等等，就只做主线。AI 领域很广泛，有很多东西我们觉得它不在这个主线上面，比如说 3D、视频生成，我觉得可能跟智能的主线没有太大的关系，我们不会去做。还有一些，比如说世界模型，我觉得现在跟智能的上限也没有太大的关系，所以我们也不会去做。但是其他人做，我们也很乐意帮忙。有没有时间是一回事，但是利益上是没有冲突的。我们也希望这些 AI 技术能够用到各种生产环境里面去，能够提高社会的生产效率，能够帮助各行各业去提高生产效率。我们是非常有动力做这个事情的。我有没有时间、有没有人手，或者我们的同学自己感不感兴趣，那是另外一回事。但是在利益上是没有冲突的，我们是希望能够达到这个目的。并且我们认为，这个跟商业没有任何冲突，我该拿到的利益还是没有少。我觉得我们之前秉持这种态度，其实我们并没有因此而少拿到任何东西，并没有因为我开源，并没有因为我们的善意或者说我对其他人提供帮助，而导致我们少拿了任何东西。比如说去年的 C 端用户，我们现在 C 端用户还是比较多的，也还是比较稳固的。我们今年的 B 端，我觉得也是比较乐观的。我并没有因为我们的善意而影响到我的商业利益，完全没有影响，反而可能还有加分。这个看起来违反直觉，但它确实是这样的。或者我们反过来想，如果违背它，也是必然的，我能够拿到更多东西吗？没有。有个问题是，怎么理解世界模型和 AI 智能上限提高没有关系？我说的是在现在这个阶段，这是我们的判断。我们有看到，这是我们自己的 AI 路线图，不是唯一的路线图。从我们的理解、从我们的判断来看，当前最重要的是把 AI 训练做好。把 AI 训练做好，并不需要世界模型，甚至不用多模态。因为你把 AI 训练范围缩小一点，没有多模态，只是有一部分任务你做不了，但是不影响这个算法的成立。多模态最终还是要做的。现在重要的是训练，然后下一步要解决的是持续学习的问题，再下一步要解决的是它自己问问题。但是这个路线图里面没有世界模型，没有视频生成。视频生成一开始出来的时候就很火，好像这是必须要做的，如果你不做，你就不是一个AI 公司一样。所以我就很奇怪，这个其实你只要仔细去想一下，它跟智能的路线图是没有什么关系的。

事实上，你也发现，那个视频生成一开始 Sora 出来之后，所有人都做，大公司、小公司都做。但是小公司后来都把它砍掉了。它跟智能的上限没有关系。但在商业上，它是个好生意，在商业上是个好生意。但是这跟智能没有什么关系。我们不会因为它是一个好商业而去做它，我们只会因为它是智能路线图上的东西，才会去做。视频生成那个，因为那个相对比较清楚，就拿它举例。然后世界模型，世界模型这个含义就没那么清楚，因为很多东西都可以说它是世界模型。从我们的判断，世界模型和智能还不是现在这个阶段最重要的事情。最重要的才是 AI 训练，以及 AI 训练之后怎么解决持续学习。这是我们公司的判断，当然每个公司它的判断是不一样的。我刚说的是，我们公司对公司来讲最重要的问题，就是人员的稳定性。从另外一个维度来讲，我们缺什么呢？我们跟美国的差距是什么？其实差距只有一点，就是资源。我们没有那么多卡，我们的卡的数量还是比较少的。我们现在大概是两万张 H 等效算力，这其中大部分是刚到，最近一两个月刚到，可能还有很多机器还没有来。我们总的算力去年比较少，今年我们在非常激进地扩充这个算力。我们现在大概是两万张H 等效，接下来几个月我们还会有大批量的机器买过来，基本上都是英伟达。我们需要多少卡？现在肯定是越多越好。在我们能够承受的范围内，肯定是卡越多越好，这是毫无疑问的。所以我们现在策略是，在合理的价格里面，能买到多少卡就买多少卡。如果说这笔融资用完之后，我能买多少卡，我就买多少卡。花钱的速度不在计划里面，而是只要价格合理，有多少我都买。那么如果说我在半年之内就把钱花完了，我觉得是个好事。如果说我在半年之内把钱都花完，那这个太幸福了，这太理想了。实际上，要把这么多钱花完非常不容易，买不到那么多卡，很难买，而且价格也很高，也不能说花非常高的价格去买，还得确保这个价格是合理的。

01:26:41

如果我半年之内就把这个钱花完的话，可能是最理想的。因为我把钱变成英伟达卡，肯定是比放在银行里面好。放银行里面，我现在已经可能是存两个点，好像就要。但是买英伟达卡，十个月的社会成本。

所以肯定是你能买到多少就买到多少。最先如果买了卡之后，后面我有很多空间，我通过提供服务或者我怎么样，我总是能够有现金流的。我有现金流我就可以活，我就不需要在我账上面放很多很多钱。所以说，我们只担心买不到那么多卡。如果能够把钱都变成卡的话，那我们会毫不犹豫把所有的钱都变成卡，并且在这里面我们是愿意付一定的溢价的。就是我们愿意付一定的溢价去把它变成卡，因为这太划算了。哪怕我们在付完溢价之后，其实我们也很难实现这个目标。那么客观上来讲，如果说我今年能够花掉两百亿，那么就属于我们的采购部门业绩超级好了。我们跟美国的差距主要在资源上面，然后人上面差距不是很大的。人上面几乎没有差距，因为就是同一批人，可能是中国人。中国人出去的时候，有一些人留在国内，有些人留在国外，有些人去国外，他并没有说是聪明的人去国外，没有的。其实它是比较随机的。最聪明的那些人，可能不是说一半多一点去国外的，但有一半少一点留在国内。国内人才是不缺的，而且我们的基数大，我们每年有那么多人的补充。人才不是瓶颈，资源是最大的瓶颈。资源首先影响到人才培养，因为算力少，我们能做的实验机会比较少，所以我们的人才整体上比美国有差距。人才的差距，本质上也是因为算力的差距。在现在最大的模型上，我们其实训不起的。我们哪怕把五百亿全花掉，其实也训不起。哪怕能堆起来也用不起。现在最大的模型，它激活大概是八百 B；国内的话，我们还在几十B 的这个规模，国内最大模型可能就几十 B 激活，那么差一个数量级。如果我要训练跟 AI 同样大的模型，应该需要五万张 GB300，或者华为 950，二十万卡。这只是训练，还没有考虑做研究。所以我们跟美国之间最大的差距是在资源上面。我们现在的资源，以及我们今年之内、接下来几个月的资源，包括马上大资源，也只足够我们在十 B 激活的这个规模里面去做更多的实验。因为我在几十 B 激活的这个规模里面，还有很多实验要做，还有很多事情需要搞清楚的。我们应该离能够训八百 B 的模型还比较远，时间还非常多，没有那么多卡。所以我们跟美国的区别，我认为就是资源上的区别。我们可能会认为，我们看到的所有区别，包括人才的区别、模型能力的区别、应用的区别，可以认为都是因为算力资源上的区别。

算力资源一方面是国内本身卡就买不到，另外一方面是我们的资本投入比美国要少。我们在资本投入层面上少了很多，基于人才的工资在这里面占的比重是很低的。你看他们开的薪水一个亿美金这种，但算起来，人才的薪水还是占比很少，大头还是算力。这个问题目前基本上无解，因为华为的产量也是有限的。因为我要训八百 B 的话，我就得二十万张华为最新的卡，这只是训练，还没有考虑做研究。所以我们现在根本就不会考虑，到这么大的一个规模上去跟美国竞争。我们现在输，还是在我们能够训练得起、能够用得起的规模上，就几十 B 激活的规模上要先把它做好。再等下一步有更多的资源的时候，再把它做到一百五十 B、一百五十六 B，或者两百五十 B激活的这个规模。所以我们跟美国在这里面有一个目前看起来很难弥补的差距。你要硬要训那么大模型也是能训，但是你没法做充分的研究。就是你在训之前，没法做充分的研究。还有个大家比较关心的问题是，所有大模型竞争，它终局的差距会体现在什么地方？就是当大模型最终差距会体现在哪里？我觉得这个差距最终可能是没有太大差距的。最终的差距应该是三方面：一方面成本，一方面时间，一方面用户体验。除此以外，可能是没有什么差距的。成本比较好理解，你提供同样的服务、同样质量的服务，你能够以什么成本来提供。同样一件服务，不如说比亚迪的电池，在同等技术量的情况下，其他家是不是能够按照这个价格来提供，我觉得这个是个较难的事情。不是那么容易做到的，肯定是壁垒。所以成本肯定是一个差异，我觉得可能成本是排在第一位的区别。然后第二个就是时间，你什么时候能够做到。你早几个月、晚几个月，它就不一样了。第三个可能是体验，用户体验还是有些不一样的。这个用户中间还是会有一些用户粘性和用户壁垒的，但它可能不本质。本质还是第一个成本，第二个时间。你先做出来还是后做出来，你做到同样东西，是快点还是慢一点。长期商业化路径和产品线进一步丰富后，怎么定价？我们觉得现在最值得做、最值得花精力的，还是做 AGI。现在要把 AGI 往前再往前推，就是把智能的下限往上推，往前推。这个应该是在现阶段，比做更多的产品线、考虑更多商业化路径更划算，或者说它是一个收益更大的路径。我觉得在未来的一段时间，以及过去的任何一段时间，可能都是这样的。就是说，如果说我们

01:39:46

我们花了很多时间去思考，丰富我们的产品有什么用吗？半年前讨论出来的商业化是什么？一定是我要去做广告，然后我要去做电商，我要去在产品里面植入电商，然后要跟本地生活什么很大一体。肯定没用的，因为变化太快了。你这个产品，如果说你在前面，或者我们现在这个阶段，去花很多时间做商业化考虑、商业化路径，产品线它生命周期很短。我觉得没有到这个时候。这是我们的判断，或者至少前面的这些经验都是支持这个判断的。在过去三年，任何一个时候你来跟我说商业化路径、产品线，都是浪费时间，因为你并不能够预测、不能够预见未来。你能够预见的是很少的。因为我看时间，不知道大家要中场休息一下吗？要先吃点东西吗？还是我们继续聊？大家没有意见，我就继续说。在做全球领先的 AGI 研究，并在适当时候进行商业化。我觉得我们一直在做商业化，我认为一直在做商业化，只是没有以商业化为目标。我们是以 AGI 为目标，但是我们一直在做商业化，所以我们才有 C 端的用户，才有 B 端的收入。从历史经验来看，这个策略是成功的。然后我觉得，我们离彻底转向商业化的时间点，应该是很遥远的。所以最大的还是技术的延伸，然后做下一代的技术，更多地解决现在的问题。这些收益比，我个人觉得，就在现在能看到的未来，在任何一个时候你聚焦在产品上都太早了。所以这也是我们克制的一部分。我希望这些商业机会能够让其他人来做，我们希望这些商业机会、怎么用这个 AI，是整个社会、我们所有的合作伙伴一起来做，大家一起来分享这个收益，而不是我想独吞，这不可能。而且我们没有那么多精力，我们的组织也没有那么多人去做这个事情。对于合作伙伴，其实我们这个融资是精心挑选的。具体怎么合作的这个提议，但首先我觉得，利益是比较一致的，就是跟我们利益最一致的、对我们最没有敌意的，或者说最希望我们能够做成功的。不是所有人都希望我们能做成功的，因为我们还是损害了很多其他人的利益的。公司重大战略、技术业务决定的流程和决策机制。我们公司整体上是建立在共识的基础上的，我并不是说我一个人决定所有事情，而是我要寻求共识。我在公司内的权威以及在公司内的影响力，是建立在共识的基础上的。比如说我要做一个事情，我肯定是先看我们大家的共识是什么，大家想不想做。然后有可能我会有一些引导或者倾向，但是这引导的作用是有限的，引导的作用是非常有限的，还是建立在一个共识的基础上。这个决策机制其实是一种寻求共识的机制，这并不是说我能够推动一个什么事情，它一定是共识，我才能够推得下去，然后我才会去推。目前主要精力基本上都在 DeepSeek 这边。我们休息五分钟。我快点写。大家可以开麦，给我一点反馈。我们这边没问题，要不然先休息五分钟。各家模型最终效果拉开差距，应该是一个综合上的。比较模型效果，肯定是得在相同的成本上来比较，这个才是有意义的。因为你比较两辆车，也是同价位的车来比较。做得好的模型跟做得差的模型，这个差别应该不是在具体某个环节，它应该是整体上的。Anthropic 跟现在超过 OpenAI，这是不是长期的？我觉得这不是长期的，这肯定是极端性的。OpenAI 和 Google，未来大概率还是会交替上升，应该是会交替上升。其实现在 Anthropic 在 Code Agent 上的优势没有那么大，其实并没有说它碾压 OpenAI。我们公司可能有一半的人，平时有一半的人觉得 OpenAI 是更好的。其实 Anthropic 它有先发优势，但这先发优势应该很快就没了，并不是一个它能够长期占得住的优势。大家这三家都很厉害，这三家里面的效率是最高的，它花的成本、它花掉的、它烧掉的钱应该是最少的。在全球 AI 中主导分工的时候，中国公司很有可能扮演的一个角色还是产量最大。常理来讲，我们的产能最大，包括芯片，芯片可能我们的产能最大，我们的电力最多，所以我们的 AI 最终很有可能我们是三体之一。中国人会把这产品做到最便宜，然后再在效果上，毕竟国外的商品，现在很多商品中国产跟美国差并没有太大的区别。未来可能 AI 也是这样，但是中国产的 AI 可能价格会更便宜。这个便宜可能是系统性的低，就跟其他行业中国提供的服务更便宜可能是一样的。我要做事情的时候，我习惯的思考是：我现在这个时候做什么收益最大？如果说我觉得现在做产品收益最大，我觉得去做产品；如果说我觉得现在把 AGI 先实现收益最大，那我就是先去做 AGI。显然，我觉得现在做产品不是收益最大的。如果你是国产卡适配的问题，国产卡现在其实是有一个历史性的机遇的。因为之前国产卡适配有一个难题，叫生态不好。就买了卡之后，但是用不起来，它没有英伟达那个生态。所以说英伟达的护城河是很强的。但是这个事情在发生变化。英伟达 CUDA 的护城河在快速地被瓦解，快速被瓦解的原因可能是有三方面。一方面是现在有了 AI，然后有了 AI 之后，我要建立起这个生态比以前容易很多了，因为 AI 可以写代码。

01:56:36

我可以用 AI 来构建这个生态，就可以把跟英伟达一模一样的生态构建出来。第一个，因为有 AI；第二个，有一些新的技术。比如说，我们家出了一个技术，叫 TileLang，是一种高级语言。用这个高级语言来写 CUDA 的算子，可以很快地把英伟达的整套生态全部都写一遍，再结合 AI，这个看起来没有什么障碍。但是现在还没有完成，还没有做完，不过这个技术路线看起来是没有什么障碍的。还有一点，因为 CUDA，英伟达它是从游戏卡演变出来的，所以它在很多地方，游戏卡的设计跟游戏卡的设置是一脉相承的。CUDA 是兼容游戏卡的。以前因为 AI 计算是一个很小的领域，比游戏卡的市场要小，所以这样是合理的。但是现在计算卡的市场已经比游戏卡更大了，就没有理由这两个还需要耦合起来。现在的趋势是，以后就不再耦合了。那么专用芯片，不管是华为还是英伟达自己，以后都是专用芯片，都不是之前的这些东西了。在这个背景下，原来英伟达生态的作用就大幅度减少了。因为对于一个专用芯片来讲，跟CUDA 没有什么关系，它跟 CUDA 是不绑定的。或者说，这个芯片在设计的时候，就已经考虑到怎么建立这个生态了。有点复杂，但 anyway，国产 AI 芯片替代现在是有个历史性机会的。我们认为，未来一年之内，我们能够看到有一个事情被验证：国产芯片的生态完全没有问题。之前认为是有问题的，认为是用不起来、不好用，但是未来我觉得一年之内，我们能够扭转这个认知，或者会用事实来扭转这些。国产 AI 芯片的硬件和生态都没有问题，唯一有问题的是产能不够。国产卡适配这一点，没有障碍，英伟达挡不住。如果是在一个正常的商业环境里面，我能买到英伟达的卡，那么国产替代是比较难的；但是在英伟达的卡买不到的情况下，所有人都迫不得已，都要去做国产芯片。在这个背景下，国产卡的适配是没有任何障碍的。国产卡建立起跟英伟达一样、甚至比英伟达还好的生态，我觉得没有障碍，但还需要时间。

我们现在主要是跟华为有合作。华为他们自己适配，但我们自己会参与这个生态，会深入参与到华为这个里面去。华为的问题还是产能不足。像华为给我们的大概是一万六千张卡的产能，互联网大厂可能是十几万张，我们一万多张，我觉得这个比例也是比较……但这已经可能是华为就这么多产能了。所以我们也没法指望在华为上面训后面那个更大的模型，或者说训练几百 B 参数激活的模型，有时就有说在今年。但是明年、后年说不定是有机会的。华为卡适配，我们主要做的工作是把它的高级语言编译器做好，把 TileLang 做好。把TileLang 做好之后，问题可能就迎刃而解了。这个事情说起来比较复杂，但是我们在做，做完之后再来解释会清晰比较多。你可以理解，V3 训练的时候，它用的还是英伟达的卡，但是已经不用英伟达的生态了。V3 用英伟达的卡，但是没有用英伟达的生态，而是我们先写一个高级编译器叫TileLang，然后基于 TileLang 的生态来完成其他所有的事情，就已经几乎不依赖英伟达的生态了。只要我把这一套东西，把这个过程重新在华为卡上做一遍，那么就完成了。我觉得这里可能是一个历史性的使命，即可以完全扭转之前大家对国产卡生态不好的认知。现在有些天时地利基本上都全了，就差时间。我觉得一年之内，应该会有很多人在上面都有，或者说都明白这问题算是解决了，剩下就是产能的问题。我对国产算力是比较乐观的。我觉得在这一点上，英伟达是在掘自己的坟墓。华为的超节点，华为的 950 超节点，在性能和价格上可以完全平替英伟达的 GB200、GB300。价格肯定要贵，但贵得有限。价格贵百分之五十、百分之一百，贵百分之一百无所谓，贵百分之两百都无所谓。比如贵百分之一百，我觉得已经可以认为在价格上可以平替了。在任务上也是可以平替的，所有 GB300 能做的任务，华为超节点都能做，延时什么都一样。唯一的代价是，四张华为卡顶一张英伟达的卡，同时落后两年。四张顶一张这个可以理解。落后两年的意思是，四张华为 950 能顶一张 GB300。落后两年是时间上落后两年。华为 950 超节点是今年 Q3 还是 Q4 的货，英伟达 GB200 是两年前 Q3 的货，差两年。英伟达今年 Q3 可能已经有新一代了。所以我们跟美国在芯片上的差距，我认为生态上以后不会再有差距，但是在芯片上是四倍加两年。

还有问题是，我们会不会向上游进行垂直整合？我希望不要。所以有个问题是，我们是不是会往上游应用进行垂直整合？我们希望不用这个，我希望是其他人来做这个事情。我不希望我把所有东西都吃了，我只要吃一块就好，我只要吃我最擅长那一块，或者我觉得我们自己认为最核心那一块，然后跟用户

02:08:18

直接相关那一块，我觉得可能对于我们的很多产业伙伴来讲，他们比我们更关注类似……应该是别人的意义，不应该我把它诠释了。未来我们会不会自建大型的集群？我觉得自建大型的集群是肯定要的，我们自己一直在做这个事情，我们所有的集群都是自己建的。但是未来要不要自研芯片，我觉得取决于这里的收益有多大，取决于收益有多大。Tesla、培育……这个事情。假如说你是运营发电厂的，你并不一定需要去造发电机，对不对？发电设备可以是别人造的，只要它的价格合理，你为什么要自己造？所以，我希望不用去做芯片。我希望能够以合理的价格买到芯片，这样我就不用去做芯片。我觉得这个很有可能是这样的，就是最近英伟达芯片的利润，不见得是可以……虽然……我们希望只做一块。我觉得 AI 这个事情很大，并不需要我……我只做一块。如果聚焦，并且我认为这里的生意利益已经足够大，就如果是 AI 时代会产生很多家万亿级别的公司，我觉得我们是其中一家。我们一直做其中一小块，我们是其中一家已经没有什么问题了，并不需要我……我并不是信心勃勃要做地方。我觉得最可能是比较难变，且你真的想做别的话，你还是会有更多的主意，这个会……这是我们的态度。譬如说，至少在 To B、To C 这两个业务上，目前能看到的，真的想做 To C 闭环的，反而我们做得好；真的想做 To B 闭环的，说不定也没有我们做得好。你想要得越多……然后还有，To B 这个可以多说几句。To B 业务的上限应该还是需求，在现在这一代AGI、AI 技术的背景下，To B 的需求应该是有限的。它会快速增长，但并不是一个无穷大的事情，最终还是受制于需求，不是算力。在当前技术的条件下，收入有多大，最终还是取决于需求。因为你这样想，我十个月就能收回成本，我肯定是如果有去处，我一块买，是因为没有那么多事情。对，需求应该会越来越大，如果随着技术持续有突破，这个需求会越来越大。

多模态布局，我们一直在做。对产品来讲，它很重要；对 C 端用户产品来讲，它很重要。但是对智能的上限，它是一个组件，它不是主线本身。但是它作为一个组件，多模态我们肯定会做，而且我们也在做。我们应该会上相关的模型，就是我们 V4、V4 的后续版本会支持原生的多模态。但是我们对多模态、对智能来讲，它是个组件，我们不把它当作智能本身，它的主线跟搜索一样。搜索也是一个组件，多模态也可以，我们的理解它也是一个组件。Scaling，我们是信Scaling，肯定是规模越大，效果越好，能够解锁更多的功能。阻止我们 Scaling 的其实就是算力，并不是我们不想 Scaling，是我们没有那么多的算力去做这个 Scaling。我们没有触摸到这个上限在哪里。我们训练这么大的模型，并不是因为我觉得这么大的模型就够了，而是我刚好有这么多资源。我是按照我的资源来算，我能够接受、能够训练的模型是多大，是这样算出来的，并不是这个模型就够了。目前来看，模型收益还是非常明显的。我们还没有机会碰到这个 Scaling 的墙，这离我们还很远。硅谷在说 Scaling 到头的时候，那是对硅谷来说；对中国人来讲，我们离那个还很远，我们根本就没有 Scaling 到那个程度。这个 Scaling 包括数据的 Scaling、模型规模的 Scaling，然后训练成本。我们离探索这个Scaling 的上限还比较远，就是没有那么多算力。但我们也会不遗余力地去推进这个Scaling 的上限。包括我们融资完之后，我们有更多的算力，可能训练更大的模型。时间内买到，就在越短时间内买到；如果能半年精力全花完，那么这是最好的，实际上做不到。下一代模型的核心能力，我觉得它必须要有持续学习的能力，它才能叫下一代模型。在那之前，我们能做的就是成本，然后效果做得更好，速度做得更快。但是要有大突破，它应该是具备持续学习的。然后还有一个问题，就是为什么好像我们特别在乎这个模型的计算效率？因为我确实发现，不是所有人都很在乎这个模型的效率。一个商业化公司来讲，没有动力去追求模型的效率，因为模型效率高一点……所以，它没有那么大的动力去追求模型效率要非常高。所以几个创业公司，他们自己并不会……你没有听到他们说低成本是他们追求的东西，因为那个不符合他们的利益。低成本了，你还赚什么钱？低成本了，你就收不到什么钱了。

相反，这是我们愿景的一部分。或者说，我们的愿景，我们的同学在乎这个成本，因为我们的同学都是普通人，他知道用这个都是要花钱的。他能够有这个同理心：别人要花钱来用，那么别人如果便宜一点，别人能够接受的程度会更高。所以我们有很多同学还是希望我们能够把成本做到更低。但是如果你从商业角度讲的话，其实不会这么考虑。从商业来讲……

02:21:31

从成本或者从商业角度讲，这不是第一优先级。对于不管是创业公司来讲，还是大公司来讲，这个服务成本根本就不高。但是我觉得我们希望它是比较轻的，我希望它是一个负担得起的，特别是在中国算力紧缺的这样的背景下，是负担得起的，能在国产卡上用的。我觉得低成本首先是一个结果。我们的模型确实一直在模型架构上往一个更低成本的方向走，这跟我们的愿景有关系。我们还有很多在算法上的方法，成本还可以往下走。成本往下走还有一个原因是，成本越低，我就越能训练更大的模型，我就越能承担起更大的模型。在同样算力上，在算力有限的情况下，如果我的计算效率更高，我就能够承担起更大的模型。对大公司来讲，他不一定会这么考虑。对大公司来讲，资源是可以加的，可以通过加资源来解决。但是我们会优先考虑成本效率。数据类模型的价值，数据这个范围比较广，数据应该几乎就等于模型的一半。为什么我会觉得，如果我想要那个，或者假如设 AI 能够占 GDP 的百分之二十，然后如果说我想要在这里面占百分之五，绝对行不通。因为我肯定会被另外一个人打败，如果另外一个人说我只要占百分之一，那么肯定就会被他打败。如果说我的目标是，我要占 AI、全人类 GDP 的百分之五，理论上算这个账还是成立的。你看 OpenAI，他算这个账好像是能算得过来的，理论上是没问题的。但是他有个问题，他会被另外一个愿意只占百分之一的人打败。因为另外一个人说，我做得这么好，但是我只要拿全球 GDP 的百分之一就可以了，那么就会把他打败。这时候如果又出来另外一个人，说我只要百分之零点一就可以了，那么又会把前面的人给打败。

从宏观上来讲，不管这百分之几是从哪里拿，彼此之间没有区别，都是一样。拿得多的人会被拿得少的人打败。甚至你还不用真的拿得多，愿景如果是拿得多的话，你就会被愿景是拿得少的人给打败。其实大家都没有拿到钱，然后只是一个愿景。你愿景是拿得多，你就先输了，你就会面临着更大的困难。这个世界就是这样。OpenAI 从一开始觉得他真的能够垄断这个世界，但是实际上他会遇到很多很多挑战者。他会遇到挑战，他就不会那么轻松。美国会遇到过的挑战，那么他在未来可能还会遇到中国的挑战，因为中国人愿意拿得更少，就可以给你提供这个服务。在中国，也会有人愿意拿得更少一点。但最后这里会有个平衡，因为你拿得太少之后，公司商业逻辑就不成立，就活不下去了。所以你拿得太少了，你活不下去；你拿太多了，你会被拿得少的人打败。所以对我们来讲，我们并不是利润要拿最多的钱，或者说算收益最大化的定价，而是只赚一个合理的收益。这是一个解释。我是相信这个事的，我并不是去为这个事情找理由，因为没必要找理由。我本来就这么做的，我这么做肯定是有理由的。这个理由可能不是非常惯常，但是我觉得公司本来就不惯常。我们公司的管理其实是两条线：一条线是从上到下，一条是从下到上。从下而上，就是每个人自己想做什么，自己做，没有人管他，没有 KPI。从上到下，就是正式的，我们要集体做一个什么事情，需要全公司的人一起来配合。比如说我们要发 V4，那么就得分工，每个人得做一部分。那个是从上到下，然后从上到下这个我们叫做正式。一般我们希望这正式不要占用员工所有时间的一半，就正式不要超过一半。他还有一半的时间，是不被安排的，他想做什么就做什么。这是一个研究的范围，让他可以自己去探索，按照他觉得什么重要，他去探索什么，没有前置的要求。只要公司能够支持，公司算力能够支持他做，或者说他不需要算力，他需要做得很少，那么他根本就不用来协调。所以我们现在是这样的一个组织方式。有些人觉得我们是从上而下的，有些人觉得我们是从下而上的，我觉得两个都对。我的一个标准是，正式最好不要超过一半。

我们一般也不太加班。加班有两个原因。第一个是，做研究是需要一个比较松弛的环境。你如果逼得很紧，就没法做研究。因为既然就是要你自己有这个兴趣，你自己平时要去想这些问题，所以得是在一个比较松弛的环境里，才有可能能够探索。这是一个出于研究文化的需要。第二个是，我们非常聚焦。我们非常聚焦，就意味着我们要做的事情很少。那我就没那么多事情要做，我就不需要加班。这个跟前面的克制是一脉相承的。因为我克制，所以很多时候我就不做了。那么我要做的事情少了，每个人分到的工作就少了。你看到我们的产品很多都不完善的，我们也没有去补它。这也是我们的一种文化。OK，因为问题很多，我大部分都扫了一遍。大家还有什么问题，大家提问。请各位投资人自由开麦交流吧。我稍微提醒一下，梁文锋讲了很多一些比较敏感的信息，请大家千万不要外传一些数字或一些情况，包括卡量什么的。同时也千万不要录屏对外做分享。很感谢各位，请各位有问题的话，自由开麦交流。

02:34:59

杨哥，您能分享更多关于持续学习什么时候带来突破的时间线吗？包括如果实现持续学习，还需要哪些架构、算法的创新，以及其他关键要素？人少，需要研究。现在全世界都在研究这个问题。或者说，对投资人来讲，现在投资人看到的最多的是 AGENT；但对于我们这些研究的人来讲，现在看到更多的是学习，以及怎么解决学习这个问题。其实学习可能不是一项技术，它是一个问题。怎么解决这个问题，可能有很多种技术，不是一项技术，它不是一个东西，会是很多东西。或者说，AGI 是由很多东西组成的，需要模型，然后还需要很多其他东西。其实它也是一个工程和算法问题。这个问题比较专业，但有很多方法，也有很多研究。梁总，谢谢。非常感谢今天这个机会。我首先非常想回应和感激一下，您最开始说的让我非常感动，也给我们很多启发。您提到，这个团队带着最大的善意，希望能够在这个行业里面，对这个社会、人类智能的发展有所推动，做一点点贡献。并且在这个里面，是带着这种使命感和愿景。我觉得这跟我们所服务公司的企业文化非常相近，就是“修己达人”。我深刻地理解了为什么您会带领团队做开源的事情。我会形象地感觉，像我们去做一个榕树这样的小鸟天堂生态，利万物而不争，但这样它就会被大家接纳，万物共生共存，最终就会无处不在。所以，我们会以这次投资，同样表达我们对这个使命和愿景的认可、支持和尊重。同时，我们也希望能够在这个产业未来，我们所擅长的一些领域等，去贡献一些力量。在这块也想跟您继续请教和探讨。比如在未来生态的共建当中，现在开源之后，这个行业里有多少伙伴、人才、团队，能够比较好地复现咱们开源目前的一些模型和成果？未来在下一步想让这个生态进一步发展的时候，您感觉在哪几个方面，需要更多高质量的人才能够衔接到我们的模型，把它复现？还是说现在 GPU 的算力相对有一些稀缺？大家未来会不会是一种模型矩阵的方式？比如咱们把大模型基模做得越来越好，各行各业的伙伴和团队去做一些模型矩阵里面的垂直行业模型，或者一些应用模型。这块目前的发展怎么样？未来一步一步，两年、三年，您感觉会长成一个什么样的生态？这是我第一个想跟您请教的。第二个，您刚才也跟很多伙伴分享了很多关于 AI 硬件方面的观察。像 AI 全球大公司，可能单体都会做千亿美元级别的投入，中国目前看起来在硬件算力上有些短板。您感觉这个多长时间可以解决，并支撑咱们 AI 的发展，让算力和硬件短板不给 AGI 拖后腿？您觉得这是不是中国人未来使命必达，我们肯定能做出来，只是时间和资金投入的问题？但同时，可能它会是两方面的。一方面，模型的进步会让模型智能化的提升，导致单一任务或者某些智能化单体对硬件、对算力的消耗逐渐递减，不再需要那么大算力的运算，因为模型的进步会让它巧算。我不知道我理解得对不对。另外一方面，硬件的技术进步会让算力的算能效能更强大。这会不会是两边相向而行的路径？现在如果是在这个时点，用现在的 960 也好，还是 H200 也好，去做千亿美元级别的算力投入，您刚才提到说您是给它按三年摊销，那它的实际生命周期，您觉得技术迭代是四五年？或者直白地说，会不会现在算力中心按现在的卡去建了万卡集群，可能三年之后它其实就是相对不那么先进的算力了？会不会有现阶段是 under construction、不够用，三年之后变成相对不那么优质的算力有冗余的情况？我不知道会不会有这样一种现象。以上两个问题请教您，谢谢。谢谢。第一个问题是生态的问题。我们现在觉得，可能每个企业都面临的问题是人才不够。但我觉得这个人才短缺会是阶段性的。我们在每个行业发展的初期，人才都是不够的。包括以前做网站，刚开始做网站的时候，做网站的人很少，人才很缺。后来互联网要做服务端，人才也是很缺的。但是这种人才短缺都非常快会被解决，也就两三年，因为会培养出大量的人。AI 人才的短缺也是阶段性的，并且我们已经看到，大幅度被缓解了。因为 AI 人真的不缺，每个公司很快会把人培养出来，培养人是很快的。所以，AI 这个行业整体上，不管是生态、模型公司还是什么，人才都不缺。人才缺肯定是一个短期现象。历史上从来没有出现过长期缺某一类人的情况。我还记得十几年前说飞行员很缺，飞行员的培养周期很长，但也很快被解决了。所以大家不用担心缺人才的问题。以及国内现在做模型的公司有点太多了，还是太多了。美国可能就三家，中国做基模的东西太多了。最终一定是不需要那么多人去做基模的，一定会收敛。所以资源也是比较分散，某种程度上也比较浪费。就先于

02:44:00

每一家都要做同样的事情，但美国只要三家做，资源只集中在这三家。中国资源分得很散，每一家拿到的资源就更少。我觉得这个肯定是会收敛的，一定会，但这需要过程，最终一定会收敛。不需要那么多家，因为现在可能大家觉得做这个事情的利润率非常高，所以一定要自己做。但当他发现这个事情可能没有那么高利润的时候，可能就不做了。最近肯定是没有那么高利润的，我不相信有那么高利润，因为这不符合客观规律。这意味着我们是处在一个阶段上：如果有一个非常高的利润率，这一定不符合客观规律。我们应该是一个合理的利润。所以这是产业的一个现状，我觉得肯定会收敛。就是大家做大模型的那一部分，其中不要说某一家独占，说“我要拿走全部利润”，这个肯定不行。如果说每一家都只拿合理的利润，那么其实不需要那么多人去做大模型。中国最后有个三四家竞争，竞争就很充分了，价格绝对已经够打价格战了。

大模型可能不说两家大公司、两家小公司，可能就已经比较够了。至于生态上的，我没有什么太多的想法。我们希望能够扶持更多的人，但是我们并没有那么多的精力。我们是有这个意愿，并且不会有利益冲突，但是我们有没有去做是另外一回事。但至少这里边是没有利益冲突的，我们是希望合作共赢的。首先，我绝对不认为大模型公司可以拿走大部分利润，这个不可能，因为这么多家大模型公司，现在差距不用那么大。差距只有两个东西：一个是时间，一个是成本。所以不至于哪一家有暴利，我觉得不至于有暴利。成本控制得好的人就多赚一点，成本控制得差的人就少赚一点，仅仅此而已。是不是有回答了？第一个问题是不是回答完了？大家能……你相信以后肯定是有很多人可以……未来其实会……大家数据应用这些的循环迭代……现在可以听到吗？谢谢。对，感谢您的回答，也非常深刻地理解和尊重您的这种行业里面的生态战略定位。比如说数据这一块，现在公开的数据，相信模型公司都已经可以有渠道获取，这个方法应该都不成问题，只是时间和成本的问题。那么后续比如说将到真正到 AGI 的时候，有可能大家一个设想或者理想的状态是，模型可以自我迭代、自我学习，就是自己训练自己。那么这一块的话，目前这个数据，您感觉仿真数据是不是可以用起来，还是说真实数据的质量最高？如果说还是需要来自于真实数据，那会不会是限制这个 AI 的智能还是在人类的过往……这个层面，因为它依赖的是人类真正曾经有过的真实数据？还是说可以突破这个上限，通过模拟数据、仿真数据、创造数据等等的方式，让这个模型能力去超越人类过往的所有真实……我觉得是能超越的。我觉得有两点超越的，比如说围棋，AlphaGo 他下了一手人类从来没有见到过的棋。就是说，他肯定是在一定的范围内超越人类的。但是他可能也有上限，他可能也是有局限性。但是这个局限性我们现在看不到。我们认为，所以笼统地认为，它是可以基于人类已经有的、我们已经能说出来的知识上，予以超越的。那这块后续是靠真实数据还是仿真数据？它会 work 吗？不可能就有很多方法。

好的，谢谢。也占用您的时间了，也想继续请教刚才关于 AI Infra 的问题。第二个问题是什么？有点……好了，我简单快速地重复一下。就是想请教，对于 AI Infra 这一块，未来相信算力现在大家都是千亿美元级别地在投入。那么这块的话，有可能我们相信中国人未来在硬件上是使命必达，有一天可能会有高效率的算力，但有可能这个在实践的过程当中，目前还是一个掣肘。那么未来会不会是两方面向下而行？一方面是模型的能力迭代之后，它其实对于算力从硬算变成巧算，所以单位模型或者任务对算力的要求和消耗会逐步地边际降低。另一方面，比如说硬件像卡的能力提升，会让迭代速度越来越快，单卡效率提升。那么这个在过程当中是怎么样的一个现象？会不会是说，现在去建了万卡集群，去买了H200 或者 960，但是过个两三年，它就变成了一个相对没有那么优质的算力，相对又变成了一个陈旧的器件？英伟达的卡基本上你可以按照五年折旧。华为的卡最多按三年折旧吧。华为 950 今年能用还挺好的，明年用我觉得还可以，后面再用我觉得可能就真的太费电了。华为卡生命周期肯定是会短一点，因为它本来就已经比英伟达晚两年了。但是我觉得差距没那么大。如果说 B200 现在能买到多少，我觉得都划算。假如说对于腾讯来讲，阿里巴巴能买到的话，再看量；如果合理价格能买到，肯定都是划算的。但不是一个算成本的时候，相信买不到。明白。我们算力落后，这是一个事实。这个事实通过三方面来消解。第一方面是我们承受模型落后，我们只能够用比他们更小的模型，小多少问题就是训练。我们要承受一定的模型落后，以及模型的尺寸更小。这落后有一个好处，落后意味着你有更多的时间，你有一定的技术，然后这样的话你就可以用巧妙的方法

02:53:59

谢谢。

所以我们跟美国的差距可能是落后美国 12 个月，落后美国可能 12 到 18 个月，或者说 6到 12 个月。反正简单说，就是落后美国两年，然后只用美国二十分之一的算力把这个事情做出来。这个叙事就是落后一到两年，但是只用它二十分之一的算力。那么未来我们要把这个叙事改写，就是我们用它几分之一的算力，但是把这个时间缩得更短，缩到 6 个月、3 个月，我觉得这是一个目标。以及我们甚至可以在某一些方面超越他们。但是在总体算力还是有数量级差距的情况下，全面超越是不现实的；但是在某一些重点、有取舍的地方，我们有一些地方超越可能是可以的。明白，谢谢梁总。信心满满，一起努力。时间也留给其他的伙伴，谢谢。感谢刚才的分享。我这边有两个快速的技术问题。在刚才聊技术路线当中，提到了我们这一阶段要解决的核心问题是持续学习，也是目前国外研究的热点，叫 RecursiveImprovement。想请教一下，目前来看，从技术上最大的难点是什么？从您的视角来看，这个什么时候可以解决？这是第一个问题。第二个问题，同时您刚才提到，先解决持续学习，然后再去做智能。我也想理解一下，您这么提背后的技术根源是什么？是不是意味着解决完持续学习问题以后，DeepSeek 后续也会做通用智能？这两个问题请教一下。技术问题其实解释起来有点……它的难点在于，我们现在还没有找到非常 work 的方法。全世界都还没有找到好的方法，大家都在摸索。所以现在还在摸索阶段，就是不知道谁能摸到下一个解决这个问题的方法。现在还在探索阶段。我们有很多思路，有很多现在看起来有前途的一些想法，但是都还没有做通。对，这是第一个。第二个是，现在我们内部比较看重这样一个叙事：训练我们的下一版模型，我们希望它能够帮助我们自己的开发。它能够提升 DeepSeek 的效率，我们的模型最首先是提高DeepSeek 自己的工作效率，让我们开发下一版模型的时候，它能够提供更多的帮助。或者说简单一点，我们做的模型，第一目标不是大家用得好用，而是我们自己用得好用。首先是对我们自己有用。对我们自己有用之后，我在开发下一版模型的时候就会更快。我们内部很多人的想法是这样的：首先要对我们自己有用，首先是给我们自己用。然后这是实现 AGI 最快的方法。当我们自己好用，那意味着可能别人也好用，但是首先得保证我们自己好用。这个叙事有点奇怪，但是确实很多人就是这么想的。而不是说用户用得好用，我是希望对我们自己帮助更大，这样我们可以实现 AGI，会快很多。所以这个叙事的逻辑是，来帮助我们实现 AGI。但首先是帮助我们实现。我们实现 AGI 需要这个帮助。现在是非常确定，我们确实需要人工智能来帮助我们实现 AGI。虽然说它还不是自主地工作，它还是只是跟人搭配，但是已经很有用了。第二个问题，就是刚才提到了，先解决持续学习的问题，然后再进入通用智能。这是您对后续的一个预期吗？想理解一下这背后的技术根源是什么？为什么先要解决持续学习，然后再进入通用智能？您对这块后续的理解。因为解决持续学习这个问题，可以大大加快我们的研发进度。如果我先解决了持续学习这个问题，那么通用智能这个问题就不在话下了。我有了 AI 的辅助，如果 AI 能够持续学习，它的能力应该是非常强的。现在的 Agent 的能力受限，是因为它不能持续学习，它不能有效地持续学习。如果说能够先把持续学习做完，那 AI 的能力是非常强的，它能够非常大地提升我们自己研究的效率。持续学习先做出来，通用智能可能就很容易了，用它来做就很容易。所以我说这是一个我们比较希望看到的结果，我们比较省力，我们就轻松。否则现在你要去人工做通用智能，它是一个比较累、比较苦，是一个数据密集、人力密集的事情，性价比也不高。感谢分享。小问题，线上的问题你看一下聊天群。觉得 AGI 还需要多久？国内硬件在这个时间能追上吗？在 Zoom 会议的那个聊天窗口里面。好，这个我看了。华为 950，现在华为是给我们一万六千卡，这应该是可以公开说的。应该是比互联网大厂少一个数量级。华为也只能给我们这么多，因为这个价格也不便宜。

互联网大厂的追求会更大，对互联网大厂来讲，它更需要。对我们来讲，我们可以买一些不合规的卡。所以我们买华为 950 的目的，还是希望帮华为把这个生态做好。一万六千卡的华为 950，只相当于四千卡的 B 系列。所以说不是一个很大的量，意义不是很大。不够训一个下一代的模型，它只够训我们现在这一代模型，不够训下一代模型。但是可以让华为把这个先做好，就是关于华为 950。然后，AGI 还需要多久？国内硬件在这个时间能追上吗？我觉得在 AI 这个事业上面，在 AI 这个事情上，应该国内一两年是能够做到跟国外差不多的，或者可能今年就能做到平替国外的模型。在 AI 这个事情上，就现在的一个方式、现在这个范式，不是很难的事情，所以今年应该就能做到的。但它还不是 AGI。

03:05:48

我至少觉得，它得能够持续学习吧。国产硬件在这个时间能追上吗？我觉得国产方面可能需要一个几年的时间。国内首先得解决生态的问题，因为生态是一个信心的问题。解决生态的问题，然后再解决产能的问题，我觉得应该是能够逐步解决的。我不太相信未来五年之后，我们还卡在产能的问题上。现在肯定是卡在产能问题上，今年、明年、后年，我觉得可能都还是卡在产能问题上，但五年之后，我觉得可能不一定，我还是比较乐观的。然后第二个问题是，思考未来的组织架构，对人员的规划规模。首先，我们之前的组织架构是非常分散的，因为没有组织架构。但是我们人在进一步扩大之后，这些肯定是需要做出一些改变的。现在只能说，这里会需要做很多改变，但现在很难一下子全部表达出来。最后应该还是要分不同的部门，应该有些部门是我们需要建立起比较严谨的层级结构的。另外一些部门，可能还是会维持一个比较松散、比较扁平的结构。随着人员的增加，我们会做这个调整。应该是我们马上就得做这个调整，因为我已经在做这个调整。已经不做这个调整的话，很多事情是没法推进下去的。确实有很多部门，是应该有组织架构的。然后大家还有问题是，CV 是先于它的哪个版本是吧？我觉得我们现在，线上发了这个GCV4 这个版本，还是比较粗糙的，然后能力方面还很多都需要时间。我们一般，对我来讲，一个比较舒适的发版节奏，大概是两三个月发一版。上次发版可能是四月底，那么下次发版可能是六月底，大概是这样子。如果没有意外的话，应该还是会一版比一版好的。在 50B 激活的这个尺度上面，我感觉最终我们跟现在的这波开源不会有太大差别。就在推理速度跟效果上，我感觉可能就不会有太大的差别。但是跟它那个大尺寸的模型，就它一个没公开的模型，应该差距还是比较大的。那个差距应该是，我们这个激活参数应该是做不到的，这就肯定得是一个更大尺寸的模型，可能比如说是 150B。那么 150B，我觉得按照我们现在训练的进度，今年，乐观的是今年年底可以开始去训练，至少是明年四……差距还是比较大的。对，这是跟 OCE 的差距。你好，我其实有一个问题，就是经常您说到这个 AGI，它实现的过程是一个渐进式的过程，而不是会有一个突变。所以我可以理解，这是一个没有临界点的过程吗？它没有临界点，但是它是非线性的。我们现在比较相信一个叙事是，AI 可以加速 AI 的研究，AI 可以加速 AI 的研究。就是说，它不是线性的，因为你可以用 AI 来加速你自己的研究，所以它到后面可能是非线性的。明白。所以当下您的这个，我理解前面的结论可能就是，语言模型继续 scaling 是够的，是足够的，做到这个状态。只能说语言模型的 scaling，我现在没有看到有上限。我们现在的智力水平，或造成美国的智力水平，都没有看到上限。明白。因为我非常好奇，就是你说，对美国来讲，800B 激活这个模型，说比它能训练起，但它也用不起来，所以它只能训练出来，它也很难拿出来给大家用了，因为确实有点贵。我之前其实很好奇的一点就是，人类其实拥有语言能力就是近十万年的事情，然后前面可能进化了三十七亿年。但在训练 AI 这个事情上，可能是可以，你说那个顺序是可以反过来的，但最终可能还是会进入到所谓，也不一定叫世界的模型，还是要进入到物理模型或者具身的那部分，是吧？就是在这个上限之后。对，我觉得具身肯定还是要进入，最终具身。所以对我们公司来讲，自然而言，可能终点都是具身。因为对一个正常人来讲，他的需求并不是电脑，对不对？因为正常的人，他吃喝玩乐、衣食住行，他不需要电脑。

他需要的是，所以他还是需要具身智能来解决具体人力的需求。如果说目标是解约人力需求的话，所以具身我觉得就是绕不过去的。明白。所以阶段性地讲，假如说到达类似，也不一定是临界点，就是可以自进化、可以比较好的自进化，或者接近这个与 SV 的这个上升的到那个时间点上，我很好奇会希望这个状态的 AI 落地的第一个让是……可能跟现在不一样。我们是希望它能够，就是直接假如说没有具身，那么我们对 AGI 的定义，或者我们希望 AGI 能做什么呢？它能帮我迭代下一版模型，能帮我迭代下一版模型一样。然后如果有了具身之后，我们希望它做的也是，让它来迭代下一版的具身，它来做下一版机器人。我还是很好奇一点，就是因为我看之前 DeepSeek 的采访等等，应该是在一些重要的方向的选择和研究的选择上面，品位和直觉是很重要的，而不是简单的工程优化。那如果之后 AI 可以自进化的话，这个品位、taste、直觉这些东西还重要，或者说重要的会是什么？AI 现在不缺品位和直觉，它缺的是持续学习的能力。AI 的品位和直觉没有问题。你让它写个文章，它的品位和直觉，我觉得没有什么问题。前面还有几个问题，我看一下那个问题。我看屏幕上谈了几个问题，但是我这边看不到了。梁总，我屏幕上留了个问题，我给您再念一下。其实是想请教一下，continuouslearning，就是持续学习，您也提到，很多研究员也提到是一个还没解决的研究问题。然后那个 coding agent，尤其是追上 MILES，就是

03:17:47

到这个 Office 水平、MIS 水平是一个比较确定的目标。对于一个还没解决的研究目标和一个比较确定的 Scaling 目标，您认为应该怎么分配研究资源，尤其是研究员这块的人才资源，怎么样才能达到最好的平衡和效果？模型 Office 是一个比较确定的目标，但是模型 MIS，我觉得还不好说是确定的，只能说是一个目标。模型 Office，我觉得应该是比较确定的。Scaling

不占资源。做朋友任意研究，他不消耗卡，只需要很少的卡，他需要的是想法；他也不消耗人才资源，因为不需要有人一直在那里做。他不是一个项目，而是需要有很多人都在那里想这个问题。所以并不需要给它分配什么资源，因为它不需要资源。你要训模型，要做模型、发模型，做模型的效率实验才需要资源。刚才讲的，对人、对卡的资源消耗都不多。所以我们叫这个叫“摸奖”。门槛很低，谁都可以去摸，但是谁能摸出什么来，这个可能我也不知道是看天赋还是看什么。所以这里并不需要我们去分配资源。只是说，我们跟其他公司不一样的地方，就是我们会花时间去讨论这个问题，会去想这个问题，然后把它当做一个重要的事情。在公司里，它是一个重要的问题，是一个我们会花时间去思考的问题，但是并不需要花很多资源去做。然后下面我还看一个问题：大模型的幻觉问题比较影响用户的体验。幻觉问题也是有一个方法可以解决的，但是这是一个长命题。幻觉问题可以认为是一个可以通过更好的 Posttraining 解决的，是一个能解、能够改善的问题。只是大家没有花很大的力气去做。或者说，对我来讲，幻觉是一个问题，但我们归结可能是产品问题。我们会去解决它，但是不是重点的问题。前面还有一个标数据的问题。我们在数据标注方面，这跟我们的资本投入有关。以我们这个资本投入的结构，支撑不起那么多高质量数据标注的成本，因为成本很高。美国数据标注的成本跟中国数据标注成本没有什么区别。中国去标数据并没有成本优势，尤其是标高端数据上并不会有成本优势，使得我们很难投入去像美国这样标数据。这条路在中国是很难的，因为标数据实在太贵了，不管是我们外标还是我们自己标，都很难受。所以现在基本上是两条腿走路。并不是说我们完全不能标，而是因为标数据有一些成本低，有一些成本高。我们先标成本低的。所以你也可以认为，现在我们公司有一半的人在标数据。有一半的核心研究员，最重要的人，有一半在标数据。我们就集中在标数据。解决 AI 这个问题，在现在这个阶段靠的就是标数据。你只要看就是一个数据。梁总，谢谢你。你讲得特别地，我们非常有感受，非常好。感谢你。我请教几个问题。CoT

第一个问题，您刚才讲，中国的模型比美国的模型在效率上肯定是强的。你讲的还有一些其他方面，未来也有可能会比美国强。你觉得是哪些方面，我们在智能或者在其他方面会比美国强？我觉得在很多体验方面，有可能我们是能比美国做得好的。即不说自己的体验，自己的产品体验觉得挺好的，我觉得我们在用户体验方面不一定会比美国差。在产品方面，产品能力上不一定会比美国差。成本应该也会比美国低，所以有可能中国还是会有竞争力的。其他方面，如果说有结构性的优势，我觉得可能也没有。但是在成本和产品这两方面，我觉得确实是有一定的结构性优势的。成本这个很好理解，是因为他们都不用做，所以他们就不发展这个能力。他们肯定没有我们重视这个事情。我们可以把它当做一个非常重要的事情，但对于他们来讲，这个是不重要的。产品也是，原生通过很多公司，产品能力还是可以的。所以我觉得这两方面可能是有结构性优势的。好的。第二个问题，请教您，您刚刚讲到后训练，我们投入相对成本又高，像 Anthropic和 OpenAI 都投入巨大的金额。这次融资以后，您觉得我们会在后训练方面加大投入吗？差距主要是在高质量数据的标注上，然后主要是在 AI 研究里面。肯定会加大投入，但是像高质量数据的标注，典型不是资本投入。高质量数据标注的瓶颈，我觉得是时间，就是需要时间。因为对 OpenAI 来讲、对国外来讲、对 Anthropic 来讲，他们都更早，然后资本更多，卡也更多。这种情况下，我们国内可以认为是最近半年才开始做，所以在时间上，我觉得是需要更多时间的。这个跟资本投入关系不太大，因为哪怕没有更多的资本投入，原来的资本也够它以最快的速度在扩张了。但是这个速度是有上限的，瓶颈不是说我能够马上有更多的人，并不卡在钱上，也不卡在卡上。但是它确实是在一个快速扩张的过程。所以我们觉得一年之内，高质量数据这个问题做得比较好，我觉得国内应该是可以预期的。我觉得面可能没有那么冷，但它确实是需要时间。

谢谢。然后第三个问题，就是我们看到 Anthropic 他们用自己的模型做自己的产品，推出了很多纵向的金融、法律……

03:29:17

甚至未来要往医疗方向走，您觉得在这种纵向应用方面，某个阶段我们也会考虑吗？我还没有想得很明白，未来我们国内的商业模式是怎么样的，或者说最顺利的路径是怎样的，我们还没有到那个阶段。国内情况和国外情况不一定一样，国内到时候是什么样，我觉得现在还比较难判断。国内我们现在以目前的情况来看的话，我觉得最合理的做法应该是全力做通用的 Agent，其他的 Agent 优先级应该更低，包括金融、医生这些 Agent。要先做 Coding，因为 Coding Agent 能够做到很多，还有很多垂直的 Agent。现阶段我们觉得最重要的，应该还是 Coding Agent。讲得很清楚，谢谢您。还有一个问题，我们也想请教您。其实我们做 DeepSeek，也很佩服您，一直在以一个非常纯粹的科研方式来做 DeepSeek。但现在这个行业确实也走到了资本市场，走到了资本化这条路上。您又是一个非常负责任的人，无论是对小伙伴还是对投资人，您也都是非常负责的。那么，在纯粹科研、纯粹做 AGI 的方向和资本市场之间的平衡，您未来肯定还要走资本市场，肯定还有公众股道，您觉得以后怎么 balance？这个您是怎么考虑的？我现在觉得应该是能够做到的，就都要。假如说我今年能够有几个亿美金的 B 端收入，再加上我们 C 端有用户，那么这本身就已经有一定的商业基础。以明年我们 B 端有收入，如果这个需求可以再增大的话，公司离净利润已经不远了，可能就已经是净利润了。可能就已经不是一个纯烧钱的阶段了，所以我感觉后面能做的、能操作的动作应该还是比较大的。或者说，最坏情况卖 API，可能都能够支撑一个上市公司。就如果说技术后面没有新的进步了，我们的技术就冻结在这里了，那么最后我们就全力卖 API，把这些服务做好，我觉得也够的。所以我觉得还是有信心的，确实没有那么难。因为确实是在一个杠杆高的地方，又在一个发展非常快的领域，它可能就是没有那么难。只能讲，我们希望有更大的梦想，但是我们也有保底可以拿出来的业绩。谢谢您，讲得很好。问题问完了，谢谢。感谢您分享。前面提到一些问题，想跟您再问一下。因为我觉得 DeepSeek 其实最大的和其他公司的区别在于，我们的组织跟其他人不一样，或者说组织形式不一样。但组织形式既跟我们的目标相关，可能也要去考虑组织自身的边界和效率。我不知道，从宏观的角度考虑，我们这个组织形式会有一个好的学习对象吗？历史上可能 Bell Labs，还是一个什么样的形态可能是比较理想的？还是说我们自己觉得也没有理想的，更多还要靠我们逐渐去探索？可能在一个新的时期，只能靠我们自己来做探索。因为我们的组织形式其实跟美国的几家公司肯定都不一样，对吧？三家公司自己也不一样，但他们至少会从一个商业公司的角度出发去探索。我可能主要想再问一下组织这个问题。首先，我们没有模仿的对象。每一步都是我们从实际情况出发，实事求是，根据实际情况来做决策，找到我们应该怎么做。所以它是一个时代的产物，或者说是现实情况的一个反应，它并不是一个模仿的结果。就是说，在这个情况下，我确实最优解可能就是这样，或者说我自己认为，我们自己选的路就是这样。每一步我们肯定都是思考过的，肯定都是选过，反正选的结果就是这么选的。它并不是因为看到谁这么选，我们这么选，而是因为我们分析了利弊而这么选。那么在未来可能也是一样，我们并没有去模仿谁。我觉得我们跟 Bell Labs 还是不一样的，因为它明确是不需要有商业化的，因为它是个……但是我们明确是要有商业化的。我们最终还是要能活下去，我们毕竟是一个公司，政府不会给我一分钱。所以我们可以有非常远大的使命，但我们归根结底是一个公司，我们要考虑怎么活着。所以 B 端对我们肯定是重要的，因为可能以后可能得靠它活着。只是说现在不重要，因为它现在是个成本线。所以我觉得这个还是不一样的，跟 Bell Labs 还是不一样的。我们本质上还是一个公司。历史上也有很多公司，它也有利润以外的追求，但并不能说它有利润以外的追求，它就不是个公司。很多公司做得很伟大，因为它有一种利润以外的追求。那个追求最后不但没有影响到它的商业化，反而能让它商业化得更好。我们本质上还是一个公司，只是说我们在考虑赚哪些钱、什么时候赚钱、赚多少钱、靠什么赚钱，只是说我们有取舍。

梁总，我有两个小问题，快速跟您请教一下。一个是说，您刚刚其实有提到 MILOS 的这个，可能不是一个很确定的目标，但是肯定会往这个方向去做。然后您也提到激活参数可能比如说……

03:41:02

下一代可能会是在 150 到 250 B 左右的一个情况。这种情况下，您觉得 150 到 250 B 是对标 O4.7，还是可能会对标到别的？这是第一个问题。第二个问题，您前面也提到了，我们现在在整个 inference 上面用了一些除了 CUDA 以外的编译语言。我理解原来咱们基于英伟达的生态，可能会用 PTX 这些比较多。现在用上更多类似您刚提到 TileLang 这些的话，是不是会大幅降低我们在 inference 上面的一些效率，或者短期降低效率？我不知道您会怎么看编译语言的这种变化带来的效率损失，还是说长期其实是一个可以补充的状态，是提高效率？是提高效率，是大幅提高效率。OK，反倒没有什么负面的影响？对，是大幅提高效率。所以说这是一个机遇。相当于以前你是离不开 CUDA 的生态的，现在我们可以抛弃它的生态，用一个更简单的方法，就用 TileLang。它是高级语言，写那个程序也是很快的，要写的代码量很小了，我可以把它重写一遍。明白。所以这两个都其实是一个，像您提到的 AI 带来的比较大的机会，不是一个可能短期需要去弥补的缺点。对，它是技术发展的大机会。它不是 AI 的机会，因为我们还有一个项目，我们在用 AI 来写 TileLang。那是不是更快？现在所有 TileLang 都是人写的，但是它已经比原来写 CUDA 的要快很多了。明白。所以哪怕是对于硬件底层的执行效率，您觉得也是没有影响？损失 1% 到 2%，我觉得是可以接受的。OK，明白，理解了。好的，谢谢您，很清晰。其他人还有没有什么问题？没问题，我们今天就先这样。好的，谢谢。非常感谢大家的时间，谢谢梁总，谢谢。拜拜。拜拜。

记录时间：2026-07-24 19:29:23

答案已经来了，痛苦却没有结束

那封信，我在心里写了七年。

我和她认识了很多年。起初是在网上争论，后来聊学习、工作、投资，也聊生活里那些没有必要专门告诉谁的小事。再后来，我意识到自己喜欢她，却一直没有说出口。我害怕打扰她，更害怕一旦说破，连原来的联系也会失去。

有一个深夜，我终于把这件事告诉了她。我写下这些年的喜欢，也承认自己的注意力常常被聊天软件拉走。我原以为，发送键按下去以后，等待会是最难熬的部分。

过了一段时间，她回复了我。她不想和我成为恋人，但她的态度比我最坏的想象温和得多。她没有厌恶我，也没有否定过去的陪伴。

关于恋爱，她的答案已经很清楚了。可我没有因此安静下来。

我开始设计今后的相处方式，甚至想用一套规则稳定彼此的联系。提出一套，又很快觉得那会成为约束，于是亲手推翻，再换一套。随后，我开始追问她为什么愿意继续联系，那句话究竟意味着什么，又设想许多年以后，我们会以什么身份回望今天。

那一天，我在对话框里留下了长长一串消息，表面上都在澄清问题，却不断生出新的问题。我想用更完整的表达消除不确定，结果把自己放进了更多等待解释的句子里。

现在回头看，那天最重要的事实很简单：她已经给出了答案，我却仍在寻找答案。

我仍在等她改变对我的感情，希望这些年的相识可以继续向前，成为一段稳定的关系，甚至走向婚姻。只要这个结果还没有出现，我就觉得一定还有什么没有说清。

后来读到罗素的《幸福之路》，我才认出这种痛苦的形状。我以为自己在研究两个人的关系，注意力却始终围绕几个关于“我”的问题打转：她怎样看我？我是否值得被爱？这些年的等待有没有意义？我还能做什么，才能让结局发生变化？

我想要的不只是“说清楚”

表白以后，我一再告诉自己，这次只是为了诚实。我压抑得太久，需要让真实的感情流动起来；至于她怎样回答，我会理解，也会尊重。

这些话是真的。把喜欢说出口以后，我确实感到轻松。但我还藏着另一个期待：希望她听完这些以后，能够改变对我的感情。

我想让她知道，这不是一时冲动。我记得我们怎样认识，记得那些聊天最密集的年份，也记得我们彼此陪伴过的时刻。我想把这些年的经历全部摆在她面前，让她看见这份感情有多长、多认真。仿佛只要材料足够完整，结论就可能发生变化。

我期待她说“我也喜欢你”，也期待这句话之后的生活：两个人继续相处，建立稳定的关系，如果合适，也许有一天会结婚。这个结果会证明这些年的等待没有白费，也会让我相信，自己最终是那个值得她选择的人。

一个回答背负了这么多东西，我自然很难把它当成普通的拒绝。她选择怎样的关系，本来只说明她的感受；到了我这里，却像是在给过去这些年、我的价值和未来的可能性一起打分。

于是，我嘴上说尊重答案，心里仍在准备补充材料。我解释自己的过去，设计以后的规则，追问她话里的含义。我把沟通当成一次尚未结束的论证，希望更准确的表达可以换来不同的结论。

这并不是蓄意欺骗她。我首先欺骗的是自己。我把“希望她喜欢我”藏在“我只想说清楚”后面，于是每次表达都可以显得合理，每次没有得到想要的回应，又都成为继续表达的理由。

需要面对的事实其实很短：我希望和她发展为恋人，她并不这样希望。这两句话都是真的。后面那些复杂的分析没有补充新信息，只让我暂时不用接受它们可以同时成立。

罗素所说的“被自己困住”

《幸福之路》第一章里，罗素回忆自己从厌恶生活变得越来越享受生活，其中一个重要变化，是他不再那么关注自己。他曾经习惯审视自己的过错、愚蠢和缺陷，后来才把注意力转向世界、知识，以及自己关心的人。

我以前把“以自我为中心”理解成自恋：一个人夸大自己，只关心自己的利益。按照这个标准，我似乎恰好相反。我总在考虑她的感受，害怕给她压力，也愿意为她付出时间。可罗素笔下的自我沉溺还有另一副面孔：不断检查自己的不足，不断想象别人如何评价自己，让所有经验最后都绕回“我怎么样”。

这样看，我那些关于她的问题，大多也在追问自己。她的一次回复，变成了“我是不是让她不舒服”；她愿意继续联系，变成了“我是不是仍然有机会”；我提出的相处规则没有得到期待的回应，变成了“我还缺少什么，才值得她喜欢”。她逐渐从一个有自己感受和选择的人，变成一面回答我是谁的镜子。

在第十二章“情爱”中，罗素用了一个让我印象很深的比喻。一艘安稳航行的船看见海岸，会欣赏海岸本身；一个刚刚沉船、正在海里挣扎的人游向海岸，爱的是它能救自己脱离风浪。后一种感情并非虚假，但它更多来自不安全，也更容易围绕自己的需要展开。

多年的交谈、理解和陪伴都真实存在。后来，这份感情又承担了越来越多原本不该由她承担的任务：证明我值得被爱，证明过去没有浪费，为未来提供一个确定方向，也让我不用独自面对生活里的空缺。

当一个人同时成为喜欢的对象、未来的答案和自我价值的证明，我就很难再自由地喜欢她。我更在意她能给我什么回应，对她的真实意愿反而看不清，也总把她的边界当成一道尚未解开的题。

罗素说，好的感情会让双方觉得整个世界更有趣。用这个标准回头看，那段时间的我没有因为喜欢一个人而更愿意走向世界。我的生活越来越窄，最后几乎只剩一个问题：她会不会喜欢我。

为什么越分析，越无法得到确定

分析一直是我依赖的能力。研究一家公司，我会拆解商业模式、财务数据和竞争格局；程序出现问题，我会查看日志、缩小范围、验证假设。只要继续寻找证据，原本模糊的问题通常会变得清楚。

我把同一套方法带进了感情。她的回复、某句话的语气、是否愿意继续联系，都成了需要分析的信号。我试着从这些细节里建立一个完整模型，判断她现在怎样看我，关系接下来会走向哪里。

这套方法在我最关心的问题上失效了。程序的运行结果遵循确定的规则，公司的经营也会留下可以交叉验证的数据；她是否想和我成为恋人，却不会因为分析更严密就改变。至于以后如何联系，确实可以商量，但它需要双方不断确认边界，推导不出一个永远有效的模型。

我当时不愿承认这种距离。我以为一套规则可以让我知道联系仍在，也能替关系划定一个稳定的位置。我像设计系统那样设计相处方式，希望每个动作都有反馈，每种沉默都有解释，每次不安都有对应的处理办法。

这些规则很快增加了新的警报。真实的互动只要偏离我的设想，我就会怀疑关系是不是又变了。为了减少不确定而增加的每一个检查点，最后都成了新的不确定来源。

那半年里，我花了大量时间等待、解释和复盘。注意力一次次从工作中被拉走，身体也开始用不舒服提醒我，事情已经不再只是“心情不好”。我明明最想重新获得控制，却连自己下一分钟会不会打开聊天软件都控制不了。

后来我才逐渐分清分析与反刍。分析会带来新证据，指向一个可以执行的动作，并允许问题在某个地方结束。反刍只是把已有的信息重新排列，期待某一种排列能导出自己想要的结论。它看起来也在思考，实际上没有新的输入，也没有愿意接受的终点。

我必须承认，有些事实不提供继续分析的入口。她可以珍惜过去，也可以不愿和我成为恋人；愿意继续联系，也不等于接受我提出的相处规则。这些态度可以同时存在。坚持从中找出另一种结论，才让我觉得它们彼此矛盾。

罗素的办法不是“别想了”

如果罗素的办法只剩一句“别想了，找点事情做”，它对我不会有多少用。那段关系持续了很多年，我期待过共同的未来，也确实失去了这种可能。痛苦有它对应的事实，并不是凭空制造出来的。

罗素也没有否认这一点。他承认幸福依赖外部处境，也承认得到爱会带来安全感，失去重要感情时悲伤无法避免。一个人如果处在严重的心理困境中，还可能需要专业帮助。他在“努力与放弃”一章讨论的是另一部分：在无法改变的事实之外，我们是否还在用自己的注意力继续扩大痛苦。

对我来说，向外关注要从停止给这段关系安排额外任务开始。她不需要证明我值得被爱，不需要评判过去这些年的经历，也不需要为我的未来提供方向。她是否愿意继续联系、愿意保持怎样的距离，都应该由她自己决定。

我的愿望也需要保留。我希望和喜欢的人建立稳定关系，希望有一天能够结婚，这些愿望没有错。一个合理的愿望也可能无法在某个具体的人身上实现。尊重这个事实，不会让过去变得虚假，也不会让喜欢本身变得可耻。

罗素在“非个人兴趣”一章中强调，能够把人带出自我沉溺的兴趣必须是真的。若我打开代码编辑器，只为检查编程能否让我忘记她，我其实仍在观察自己的情绪。

变化发生在问题本身重新吸引我时。我开始关心一个功能为什么没有按预期运行，一个产品究竟解决了谁的问题，一家公司如何建立长期优势，一条短视频怎样把复杂的东西讲清楚。投入其中时，我会忘记检查自己有没有好一点。

外部兴趣不会保证从此不再想起她。某个日期、一句话或一段旋律，仍然可能把记忆带回来。它出现，停留一会儿，而生活中还有项目、家人和许多尚未理解的问题等着我。我对她的喜欢也许还会存在，只是不再占据生活的全部。

重新打开那个 AI 项目

现在，我手里有一个使用 AI 辅助编程的项目。它一头连着我想获得的 AI 全栈工程经验，另一头连着价值投资：项目完成以后，可以帮助我持续收集和整理公司资料。

这两件事都需要很长时间。全栈能力不会因为完成一个页面突然出现，对一家公司的理解也不会从一份财报里自动长出来。我要学习新的技术，处理前后端之间的问题，判断哪些资料值得收集，再把零散信息组织成可以用于投资判断的东西。

过去那半年，这些本来值得投入的问题经常被同一个念头挤到旁边。代码写到一半，我会想起某条消息；工作刚进入状态，又忍不住确认她是否回复。相比一个需要数月推进的项目，聊天软件里的反馈来得更快，也更直接。只是每次查看都没有真正解决问题，只会让我更期待下一次查看。

我现在仍然不能保证，重新打开项目以后就不会想起她。也许写到一半，注意力还是会飘回过去。但我可以不再顺着那个念头打开聊天记录，而是把眼前这一小段代码写完，把没有跑通的功能再检查一遍，把下一家公司的资料放进系统。

这些动作不会替我证明自己值得被爱，也不会让过去的故事得到另一个结局。它们有自己的结果：功能能否运行，资料是否完整，我有没有比昨天更理解 AI 工程，也有没有更接近一个可靠的投资判断。

读《幸福之路》以前，我以为幸福需要先解决自己：想清楚所有情绪，确认别人如何看我，替过去找到意义，然后才能安心地生活。现在我愿意把顺序调过来。先去做那些本来就重要的事，注意力才有机会离开关于自己的循环。

所以，我不准备等到彻底放下以后再开始。聊天记录可以留在那里，遗憾也可以暂时没有结论。我重新打开代码编辑器，接着完成那个 AI 项目。屏幕上还有许多问题，但它们终于不再是“她为什么不喜欢我”，而是“这个东西怎样才能运行起来”。

记录时间：2026-07-24 17:10:59

这篇笔记整理自一次关于 AI 写作辅助 Skills 的讨论。

想用 AI 写一篇书评或读后感时，最容易找错工具。很多人首先想到 Humanizer，希望它把文章改得更像人写。一篇读后感却要先回答四个问题：作者说了什么，他的论证是否成立，这些观点与我有什么关系，我最终形成了什么判断。

Humanizer 只能处理最后一层。它可以删掉机械连接词、压缩空话、调整句子节奏，却无法替作者产生真实经历、价值判断和阅读中的疑问。写《幸福之路》这样的经典作品，与其寻找一个万能 Skill，不如把不同阶段交给不同工具。

一套更合适的组合

我会选择四个 Skills：

1. Content Research Writer：整理材料、提炼问题和建立初步提纲。
2. Doc Co-authoring：明确读者、中心问题和文章结构，分段完成初稿。
3. Avoid AI Writing：检查模板化表达、空洞判断和缺少作者立场的段落。
4. Humanizer：在不改变事实与观点的前提下，完成最后一轮语言打磨。

四个 Skills 各自负责一个环节：研究、组织、审查、润色，无需把同一篇文章重写四遍。在组织和审查之间，还要由作者本人提供材料。

第一步：先把书拆开

Content Research Writer 适合处理前期材料，但不应该一上来就让它写读后感。更好的任务是梳理全书的核心论证：罗素如何解释人的不幸福，他提出了哪些幸福来源，观点之间有什么因果关系，哪些判断今天仍然成立，哪些带有时代局限。

以《幸福之路》为例，可以要求它分别整理：

• 过度自我关注、竞争、嫉妒、负罪感和舆论恐惧如何制造不幸福。
• 对人、工作、知识和外部世界的兴趣为何可能带来幸福。
• 罗素的论证依赖哪些前提。
• 哪些观点适合联系个人经验，哪些值得提出反对意见。

这一步产出一份问题地图，距离可以发布的文章还有很远。逐章摘要看似完整，却很容易把读后感写成一本书的压缩版。

第二步：确定自己真正想说什么

Doc Co-authoring 最有价值的地方，是帮助作者从材料中选择一条主线。文章不需要覆盖全书，而要回答一个值得写的问题。

例如，可以把《幸福之路》的中心问题定为：

罗素认为，过度关注自己恰恰是不幸福的重要来源。为什么把兴趣投向外部世界，反而能够减轻内心的痛苦？

围绕这个问题，文章便可以自然地形成四部分：罗素诊断了什么，他给出了什么答案，这个答案如何解释自己的经历，以及它有哪些边界。中心问题决定结构，原书的章节顺序只作为参考。

如果只能安装一个写作 Skill，我会选择 Doc Co-authoring。它能帮助作者找到文章的中心，区分复述与思考，并让每一部分都服务于同一个问题；把句子写顺反倒是后面的事。

第三步：加入不能外包的个人材料

这一步没有哪个 Skill 能代替。动笔前，作者至少应该回答几个问题：

• 哪个观点最让我意外？
• 哪个观点与我的经历吻合？
• 哪个观点我并不完全同意？
• 读完以后，我准备改变什么行为？
• 书中的解释在哪些情况下可能失效？

如果文章讨论“过度关注自己”，就应该写一次具体的自我审视如何变成反刍，一句别人的评价如何在脑中反复播放，或者当注意力真正放到工作、学习与创造上时，情绪发生过什么变化。

写具体不等于暴露隐私，只需交代情境、选择和结果。“我深受启发”没有提供这些信息。一段不那么漂亮但确实发生过的经验，通常比一页流畅的通用感想更有作者感。

第四步：先审查，再决定怎样改

初稿完成后，可以让 Avoid AI Writing 查找问题，但先不要让它直接重写全文。更有用的做法是要求它标出：

• 哪些段落像通用的书籍摘要。
• 哪些句子正确却空洞。
• 哪些判断缺少证据或个人立场。
• 哪些部分只是在复述原书，没有回应原书。
• 哪些句式和段落长度过于整齐。
• 哪些地方需要补充具体经历、保留意见或行动变化。

审查与改写分开，作者才有机会判断建议是否合理。一次性重写全文虽然省事，却可能把原本真实的表达也一并抹掉，最后只得到另一种更隐蔽的模板。

第五步：最后才用 Humanizer

Humanizer 适合收尾。它可以删除机械式连接词，减少套路化排比，压缩重复总结，调整长短句节奏，让书面表达更自然。但调用时需要明确边界：

保留原有观点、经历和表达习惯；不要增加事实，不要虚构个人经历，不要把文章改成网络鸡汤，也不要为了所谓“像人”而加入错别字或不规范表达。只修改明显机械、空洞、重复和模板化的句子。

Humanizer 应该扮演文字编辑：让已有的思想更清楚，同时不替作者制造思想。

一条完整的读后感工作流

把这些步骤连起来，大致是：

阅读并做笔记
      ↓
Content Research Writer
拆解原书的观点、论证与争议
      ↓
作者回答个人问题
补充经历、赞同、反对与行动
      ↓
Doc Co-authoring
确定中心问题并组织初稿
      ↓
Avoid AI Writing
标出模板化、空洞和缺少作者感的部分
      ↓
Humanizer
做最后一轮语言润色
      ↓
作者本人通读、删改和确认

只选两个工具时，可以保留 Doc Co-authoring 与 Humanizer：前者负责思想和结构，后者负责表达。条件允许时，再加入 Content Research Writer 和 Avoid AI Writing，形成完整的前期研究与后期审查。

目标不是骗过检测器

没有任何 Skill 能保证文章“无法被判断为 AI 写作”，AI 检测器本身也可能误判。使用这些工具时，目标应当是提高文章质量，并保留稳定的作者声音。

作者自己的阅读路径，才会让一篇读后感与通用生成文本拉开距离：为什么被某个观点击中，为什么对另一个观点保留怀疑，过去的经验如何支持或反驳作者，读完以后准备怎样行动。故意替换几个词产生不了这些内容。

因此，这套流程里最重要的“第五个 Skill”，始终是自己的阅读笔记。AI 可以帮助拆书、搭结构、找问题和磨句子，但只有作者本人能决定：这本书最终改变了我什么，又有哪些地方没有说服我。

记录时间：2026-07-23 09:59:31

第一次看到 Superpowers 提供的 14 个 Skills，很容易把它们理解成一张从上到下逐项执行的检查表。照这种理解，每次改代码都要先头脑风暴、写设计、拆计划、创建 Worktree、派发子代理、做 TDD、请求评审，再走完分支收尾。哪怕只是修改一行文案，也像在启动一个完整的软件项目。

但这 14 个 Skills 并不是 14 个顺序执行的步骤。它们共同组成一套开发流程：其中 9 个构成从点子到 Git 集成的主线，另外 5 个在调试、并行、评审反馈或 Skill 开发时按需插入。

一条主线，几种条件分支

Superpowers 的主流程可以画成这样：

flowchart LR
    A["using-<br/>superpowers<br/>选择流程"] --> B["brainstorming<br/>明确点子与设计"]
    B --> C["writing-plans<br/>拆实施计划"]
    C --> D["using-git-<br/>worktrees<br/>隔离工作区"]
    D --> E{"选择执行方式"}
    E --> F["subagent-driven-<br/>development"]
    E --> G["executing-plans"]
    F --> H["test-driven-<br/>development"]
    G --> H
    H --> I["requesting-<br/>code-review"]
    I --> J["verification-<br/>before-<br/>completion"]
    J --> K["finishing-a-<br/>development-<br/>branch"]
    K --> L["合并 / 推送 PR / 保留 / 丢弃"]

它表达的不是“调用完一个 Skill，再调用下一个 Skill”这么机械。更准确地说，每个 Skill 负责守住一个开发关卡：

1. using-superpowers 判断当前任务需要哪些方法。
2. brainstorming 把模糊想法变成经过确认的设计。
3. writing-plans 把设计拆成可以逐项执行和验证的步骤。
4. using-git-worktrees 为实施创建隔离环境，并确认基线正常。
5. subagent-driven-development 或 executing-plans 负责执行计划，两者选择其一。
6. test-driven-development 约束每项代码修改的实现节奏。
7. requesting-code-review 在阶段任务完成后引入独立审查。
8. verification-before-completion 用最新、完整的命令结果证明任务已经完成。
9. finishing-a-development-branch 处理合并、PR、保留或丢弃分支。

这里的“发布”主要指完成 Git 集成与 Pull Request，并不等于生产部署。Superpowers 没有专门负责上线生产环境的 Skill；真正的部署、冒烟测试、监控与回滚，仍然要使用项目自己的脚本或其他部署 Skill。

异常流程按需插入

主线之外的 Skills 不是遗漏的步骤，而是条件触发的处理方法。

• 出现 Bug、测试失败或异常行为时，插入 systematic-debugging，先查根因再修复。
• 收到人工或外部评审意见时，插入 receiving-code-review，先验证意见是否适用，再逐项修改。
• 同时存在两个以上真正独立的问题时，使用 dispatching-parallel-agents 并行调查或修复。
• 创建或修改其他 Skill 时，使用元技能 writing-skills。

这也解释了为什么不能把 14 个 Skills 排成一条直线：调试、并行和接收评审都依赖具体情境，不应该在每个任务中强制发生。

从点子到 Git 集成

完整流程从识别任务类型开始。using-superpowers 会先检查可用 Skills，并决定当前任务适合走哪条路径。用户的明确指令优先级更高，因此这一步不是替用户增加流程，而是选择恰当的方法。

对于新功能、UI 或行为修改，brainstorming 先阅读项目、逐个澄清问题、比较两到三个方案，形成经过用户确认的设计。随后，writing-plans 把设计拆成短小步骤，明确文件路径、接口、代码、测试命令和预期结果。

进入实施前，using-git-worktrees 检查当前工作是否已经隔离。必要时创建 Worktree、安装依赖并运行基线测试，避免后续修改污染正在使用的分支。

执行计划时有两条路：

• executing-plans 由当前代理直接逐项实施，适合计划明确且不需要子代理的任务。
• subagent-driven-development 为相对独立的计划项安排全新的实施代理，再进行规格与质量评审。实施代理通常依次修改代码，不等同于并行开发。

无论选择哪个执行器，代码修改都通过 test-driven-development 完成：先写失败测试并确认红灯，再写最小实现让测试转绿，最后在测试持续通过的前提下重构。如果中间出现失败，则切换到 systematic-debugging，通过稳定复现、证据收集、单一假设和最小实验定位根因。

阶段任务完成后，requesting-code-review 根据 base 与 head SHA 派发独立评审，优先处理 Critical 和 Important 问题。全部实现完成后，verification-before-completion 重新运行能够证明结论的完整命令，读取输出与退出码，避免用旧结果或主观判断宣布成功。

最后，finishing-a-development-branch 再次确认测试、分支和基线状态，让用户从合并、推送 PR、保留分支或丢弃工作中作出选择，并按选择清理 Worktree 与分支。

14 个 Skills 各自负责什么

三类角色更容易记

如果不想记住 14 个名字，可以按角色理解：

主线关卡负责把一个想法推到可集成状态，包括 using-superpowers、brainstorming、writing-plans、Worktree 管理、执行器、TDD、评审、验证和分支收尾。

条件工具在特定情境下介入，包括并行代理、系统调试和接收评审。请求代码评审通常位于主线上，但对于很小的任务也可以按风险决定是否使用。

元技能只有 writing-skills，它不直接开发产品，而是用测试驱动的方法开发其他 Skills。

它为什么显得很重

Superpowers 主要面向中大型、需要审计或多人协作的开发任务。它把设计、计划、隔离、实现、评审、验证和 Git 集成全部设为显式关卡。这样做提高了可追踪性，也能减少代理在长任务中偏离需求、跳过测试或过早宣布完成的风险。

代价同样明显：设计文档、实施计划、Worktree、子代理评审和分支收尾都会产生固定成本。直接把完整流程套在改文案、改配置或局部样式这类小任务上，流程成本可能高于代码修改本身。

因此，正确的用法不是“每次执行全部 14 个 Skills”，而是先识别任务的规模、风险和协作方式，再选择需要经过的关卡。中大型功能可以走完整主线；已有设计的任务可以从计划或执行阶段开始；小改动则保留必要的实现与验证，省略不会降低风险的环节。

Superpowers 真正提供的不是一份冗长清单，而是一套可以按风险裁剪的开发控制系统。主线保证工作从想法走到可验证、可评审、可集成的结果，插入式技能负责处理异常和协作，元技能则让这套方法本身也能被测试和改进。

记录时间：2026-07-22 12:36:12

这篇笔记整理自我对个人项目 AI 开发流程的一次复盘。

工具变多以后，我先划清职责

我给 Codex 安装了不少 Plugins 和 Skills。工具一多，同一个任务会触发几套流程：一个 Skill 要写规格，另一个要建计划，还有一个准备创建工作树。项目目录很快多出 specs/、plans/、tasks.md 和检查清单。AI 忙着执行方法，我却要花时间管理 AI 生成的方法文件。

个人项目需要一套边界清楚的分工：

我用一句话记住这套分工：AGENTS.md 管长期规则，Master Prompt 管当前任务，Skills 提供执行方法。

AI 可以承担重复实施、测试和审查。产品方向与范围仍由我决定。这样既能利用工具，也不会让工具替项目建立另一套制度。

四个阶段，各自回答一类问题

我把项目推进过程分成四段：

DISCOVERY
产品问题探索
    ↓
PRODUCT_DESIGN
产品流程与静态原型
    ↓
IMPLEMENTATION
框架选择、技术设计与编码
    ↓
RELEASE
Staging、部署、回滚与监控

阶段边界可以挡住不少返工。

讨论产品时，我把注意力放在用户问题上。进入实现后，我按确认过的范围写代码。发布阶段保留验证和回滚步骤，不用上线压力为新需求开口子。

项目文档保持固定

一个个人项目不需要多套平行文档。我长期维护下面这些文件：

README.md
AGENTS.md
CHANGELOG.md

docs/
├── product.md
├── ux.md
├── architecture.md
├── operations.md
├── ai-workflow.md
└── features/
    └── <feature>.md

product.md 记录用户问题、产品定位、MVP 和明确放弃的范围。ux.md 保存用户流程、页面结构与原型结论。architecture.md 管技术栈、数据模型、API 和技术决策，operations.md 管部署、备份与回滚。

单个功能的需求、计划、验收和状态都放进 features/<feature>.md。我在 ai-workflow.md 保存可复用的 Prompt 与 Skill 用法，在 CHANGELOG.md 记录已经发布的变化。

这套目录也写进 AGENTS.md。Skill 默认建议的 specs/、docs/superpowers/、plans/、tasks.md 和 review.md 不进入项目。AI 要更新文档时，先取得我的确认，再修改指定文件。

每个任务用一份 Master Prompt

长期规则无法描述眼前任务。我会在每轮工作开始时补一份任务单：

请先阅读 AGENTS.md，并严格遵守。

当前阶段：
<DISCOVERY / PRODUCT_DESIGN / IMPLEMENTATION / RELEASE>

本次任务：
<一句话说明任务>

输入：
- <相关文档>
- <样例数据或当前代码>

允许使用的 Skills：
- <Skill 1>
- <Skill 2>

本次输出：
1. <结果 1>
2. <结果 2>

明确不包含：
- <范围外事项>

限制：
1. 不创建新的文档目录。
2. 不使用 Skill 的默认文档路径。
3. 不修改与本任务无关的文件。
4. 执行前先给出计划，等我确认。
5. 未经确认，不提交、推送、合并或部署。
6. 完成后列出修改文件、验证结果、尚存风险和人工测试步骤。

这份 Prompt 给 AI 一张当前任务单。AGENTS.md 不必塞入每次任务的临时要求，任务结束后也不用清理长期规则。

Skills 按工作风险选择

我保留一组覆盖开发关键环节的 Skills：

项目还可以创建少量领域 Skill。例如，内容系统可以用 content-package-contract 约束 manifest.json、正文、资源、来源和校验和；阿里云项目可以用 aliyun-release-checklist 固定镜像、迁移、冒烟测试与回滚步骤。

项目规模增长以后，我再加入分支收尾、代码审查反馈或 Worktree 管理。并行 Agent 与完整规格套件会增加协调成本，当前阶段用不到。

插件与单个 Skill 的选择

我用两个条件判断是否安装完整插件：插件需要连接外部系统，或包内大部分 Skills 都会进入日常工作。

GitHub Plugin 值得完整安装。它能读取仓库、Issue、Pull Request 和 CI，外部连接能力构成了插件价值。Superpowers 更适合挑选其中常用的 Skills，例如计划、测试、调试和完成前验证。这样可以避开未使用流程的默认行为。

Spec Kit 暂不加入。它生成的 spec.md、plan.md 与 tasks.md 会和现有文档重复。等项目出现多人协作、跨模块依赖或长周期需求，再评估这套投入。

自动调用保持克制

我允许 verification-before-completion 自动触发，因为每次交付都需要新鲜的测试或构建证据。systematic-debugging 可以自动触发，也可以在出现稳定故障后手动调用。

设计、计划、TDD、代码审查和浏览器验收由我手动指定。这些方法会改变任务节奏，也可能创建文件或扩大工作范围。手动调用让我在使用前先判断成本。

一套适合个人开发者的 AI 工作流，不靠工具数量衡量。规则要稳定，任务要具体，方法要服从当前阶段。我维护这三层边界，AI 才能把时间花在实现、验证与审查上。

从本地 Docker Compose 到阿里云 ECS：企业研究资料库部署实录

记录日期：2026-07-21
项目栈：Nuxt、Vue/Vite、FastAPI、PostgreSQL、Docker Compose、Nginx
服务器：阿里云 ECS，CentOS Stream 9，x86_64
发布边界：公网只读，管理端通过 SSH 隧道访问

摘要

这次部署把一个运行在 Mac 上的五服务 Docker Compose 项目搬到阿里云 ECS。公开站点使用备案域名和 HTTPS，管理端没有登录系统，因此不能暴露到公网。宿主机 Nginx 只开放公开阅读接口，拦截 /admin/ 和 API 写方法；管理员通过 SSH 本地端口转发进入 Compose 的回环端口。

部署过程遇到了几类典型问题：Docker 官方仓库连接被重置、Docker Hub 镜像拉取超时、Apple Silicon 与 ECS 的 CPU 架构不同、docker save 导出的镜像不完整、FastAPI 因 CORS 配置拒绝启动、Nginx 使用源码安装目录且没有 systemd 服务、旧 HTTPS 证书过期、DNF 进程被 Ctrl+Z 暂停并占用锁。

为避免泄露信息，文中的服务器地址统一写成 <ECS-IP>，数据库密码写成 <随机密码>，阿里云账号专属镜像加速地址写成 <镜像加速地址>。

一、项目和部署目标

项目包含五个 Compose 服务：

HTML 文件按原文保存并嵌入阅读器。Markdown 文件同时保存 source.md，后端使用统一模板生成 rendered.html。数据库只保存索引，文件正文存入 Docker 内容卷。

本轮部署设定了四个约束：

1. 公网只能阅读资料。
2. 管理端和写接口不能直接暴露。
3. PostgreSQL 与内容文件必须持久化。
4. ECS 无法访问 Docker Hub 时仍能更新版本。

二、最终架构

Internet :80/:443
  └── 宿主机 Nginx（/usr/local/nginx）
        ├── HTTP 跳转 HTTPS
        ├── 公网 /admin/ 返回 404
        ├── 公网 /api/ 仅允许 GET、HEAD、OPTIONS
        └── 127.0.0.1:8080
              └── edge 容器
                    ├── web:3000
                    ├── admin:8080
                    └── api:8000
                           └── postgres:5432

管理员 Mac
  └── SSH -L 18080:127.0.0.1:8080
        └── http://127.0.0.1:18080/admin/

阿里云建议把安全组当作白名单，只开放业务需要的端口。公开 Web 服务需要 80 和 443，SSH 使用 22；数据库、内部 API 和管理端端口保持关闭。阿里云 ECS 安全组指南

安全组按以下目标配置入方向规则：

3000、8000、8080、5432、18080 不加入安全组。Linux ECS 也不需要开放 Windows RDP 的 3389。

三、服务器环境盘点

部署前先确认操作系统、架构、身份、磁盘和已有软件：

cat /etc/os-release
uname -m
whoami
docker --version 2>/dev/null || echo "Docker 未安装"
docker compose version 2>/dev/null || echo "Docker Compose 未安装"
nginx -v 2>&1 || echo "Nginx 未安装"
df -h /

这些命令分别回答六个问题：

现场结果如下：

• CentOS Stream 9，x86_64。
• Nginx 1.28.0 已安装。
• Docker 和 Compose 尚未安装。
• 根分区 40 GB，剩余空间约 36 GB。

四、安装 Docker：官方仓库连接被重置

4.1 症状

使用 Docker 官方 CentOS 仓库安装时，DNF 在下载 containerd.io、docker-ce 和 Buildx 插件时多次报错：

Curl error (35): SSL connect error
OpenSSL SSL_connect: Connection reset by peer
No more mirrors to try

包管理器本身能工作，DNF 数据库没有损坏。失败集中在 download.docker.com:443，指向 ECS 到 Docker 官方站点的网络链路。

4.2 处理

Docker 官方文档要求在 CentOS 上先配置 RPM 仓库，再安装 Engine、CLI、containerd、Buildx 和 Compose 插件。Docker Engine on CentOS

本次把仓库地址切换到阿里云 Docker CE 镜像：

dnf install -y dnf-plugins-core

dnf config-manager --add-repo \
  https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

dnf install -y \
  docker-ce \
  docker-ce-cli \
  containerd.io \
  docker-buildx-plugin \
  docker-compose-plugin

systemctl enable --now docker

阿里云开发者社区提供了 Docker CE 镜像地址和 CentOS 安装示例。阿里云 Docker CE 镜像

命令含义：

• dnf-plugins-core 提供 dnf config-manager。
• --add-repo 将软件仓库写入 /etc/yum.repos.d/。
• systemctl enable --now docker 同时启动 Docker 并设置开机启动。

安装完成后验证：

docker --version
docker compose version
systemctl is-active docker

现场版本为 Docker 29.6.2、Docker Compose v5.3.1，服务状态为 active。

五、上传项目和隔离秘密

5.1 服务器目录

mkdir -p \
  /srv/company/app \
  /srv/company/backups \
  /srv/company/secrets

目录职责如下：

• /srv/company/app 保存代码和 Compose 文件。
• /srv/company/secrets 保存生产环境变量。
• /srv/company/backups 保存数据库与内容卷备份。

5.2 从 Mac 上传代码

rsync -az --delete \
  --exclude='.git/' \
  --exclude='.worktrees/' \
  --exclude='.env' \
  --exclude='node_modules/' \
  --exclude='.venv/' \
  --exclude='.nuxt/' \
  --exclude='.output/' \
  --exclude='dist/' \
  --exclude='var/' \
  /Users/<USER>/Desktop/code/company/ \
  root@<ECS-IP>:/srv/company/app/

参数说明：

--delete 会改变远端目录。使用前要确认目标路径是 /srv/company/app/，并排除 .env 与运行数据。

服务器用以下命令确认上传结果：

cd /srv/company/app
test -f compose.yaml && echo "项目上传成功"

5.3 创建生产环境文件

POSTGRES_PASSWORD="$(openssl rand -hex 32)"

install -m 600 /dev/null \
  /srv/company/secrets/company.env

tee /srv/company/secrets/company.env >/dev/null <<EOF
POSTGRES_DB=company
POSTGRES_USER=company
POSTGRES_PASSWORD=$POSTGRES_PASSWORD
DATABASE_URL=postgresql+psycopg://company:$POSTGRES_PASSWORD@postgres:5432/company
CORS_ORIGINS=http://localhost:3000,http://localhost:5173
CONTENT_ROOT=/data/content
EOF

chown root:root /srv/company/secrets/company.env
ln -sfn /srv/company/secrets/company.env /srv/company/app/.env

openssl rand -hex 32 生成 32 字节随机值并用十六进制表示。install -m 600 创建只允许所有者读写的文件。软链接让 Compose 仍能从项目目录找到 .env，秘密文件本体留在独立目录。

检查权限时不输出密码：

stat -c '%a %U:%G %n' \
  /srv/company/secrets/company.env

grep -E \
  '^(POSTGRES_DB|POSTGRES_USER|CORS_ORIGINS|CONTENT_ROOT)=' \
  /srv/company/secrets/company.env

期望权限为 600 root:root。

六、Docker Hub 超时：镜像加速器也没有解决全部问题

6.1 配置阿里云镜像加速

阿里云 ACR 会为账号生成专属镜像加速地址，Docker 可以在 /etc/docker/daemon.json 中配置 registry-mirrors。阿里云 ECS Docker 指南

mkdir -p /etc/docker

tee /etc/docker/daemon.json >/dev/null <<'EOF'
{
  "registry-mirrors": [
    "<镜像加速地址>"
  ]
}
EOF

systemctl daemon-reload
systemctl restart docker

docker info | sed -n '/Registry Mirrors/,+3p'

docker info 能看到加速地址，说明 Docker 已读取配置。账号专属加速地址不应写入公开仓库。

6.2 新问题

执行下面的命令仍然失败：

docker pull postgres:18.4-alpine

返回结果是镜像 not found。另一个镜像请求直接访问 registry-1.docker.io:443 时出现超时。加速器改善访问路径，但不能保证缓存或代理每个指定标签。

项目包含五个镜像，其中三个需要本地构建，另外两个来自 Docker Hub。继续在 ECS 上反复拉取会让部署结果受网络波动支配。部署改用离线镜像包。

七、Apple Silicon 与 ECS 架构不同

7.1 架构检查

开发 Mac 使用 ARM64，ECS 使用 AMD64。把 Mac 默认构建的镜像复制到 ECS，容器可能报 exec format error。

Docker Buildx 支持用 --platform 指定目标平台；单平台结果可以通过 --load 写入本地镜像库。Docker 多平台构建、Buildx --load 说明

三个应用镜像使用以下模式构建：

docker buildx build \
  --platform linux/amd64 \
  --load \
  -t company-research-library-api:ecs-amd64 \
  apps/api

docker buildx build \
  --platform linux/amd64 \
  --load \
  -t company-research-library-web:ecs-amd64 \
  -f apps/web/Dockerfile \
  .

docker buildx build \
  --platform linux/amd64 \
  --load \
  -t company-research-library-admin:ecs-amd64 \
  -f apps/admin/Dockerfile \
  .

7.2 docker save 的 20 字节陷阱

第一次执行 docker save | gzip 时，Docker 报告某个 manifest 的内容摘要不存在。管道仍留下一个约 20 字节的 .tar.gz 文件。文件存在不代表镜像包可用。

本次为 PostgreSQL 和 Nginx 再构建一层只含 FROM 的单架构包装镜像：

FROM postgres:18.4-alpine

FROM nginxinc/nginx-unprivileged:1.30.4-alpine

对应标签为：

postgres:ecs-amd64
nginxinc/nginx-unprivileged:ecs-amd64

随后逐个检查镜像架构：

docker image inspect <IMAGE> \
  --format '{{.Architecture}}/{{.Os}}'

五个结果都必须是：

amd64/linux

7.3 导出、校验和传输

Docker 官方文档支持把多个镜像写入 tar 流，再用 gzip 压缩。docker image save

docker save \
  company-research-library-api:ecs-amd64 \
  company-research-library-web:ecs-amd64 \
  company-research-library-admin:ecs-amd64 \
  postgres:ecs-amd64 \
  nginxinc/nginx-unprivileged:ecs-amd64 \
  | gzip -1 \
  > /tmp/company-ecs-amd64-images.tar.gz

gzip -t /tmp/company-ecs-amd64-images.tar.gz
shasum -a 256 /tmp/company-ecs-amd64-images.tar.gz

最终镜像包约 319 MB。gzip -t 检查压缩结构，SHA-256 用于确认网络传输前后字节一致。

上传时保留进度和断点信息：

rsync -avP \
  /tmp/company-ecs-amd64-images.tar.gz \
  root@<ECS-IP>:/srv/company/

ECS 重新计算哈希，结果与 Mac 一致后导入：

sha256sum \
  /srv/company/company-ecs-amd64-images.tar.gz

gzip -dc \
  /srv/company/company-ecs-amd64-images.tar.gz \
  | docker load

gzip -dc 解压到标准输出，docker load 从标准输入读取镜像归档。整个过程不生成额外的未压缩 tar 文件。

Compose 期望固定标签，因此导入后重新标记：

docker tag \
  company-research-library-api:ecs-amd64 \
  company-research-library-api:latest

docker tag \
  company-research-library-web:ecs-amd64 \
  company-research-library-web:latest

docker tag \
  company-research-library-admin:ecs-amd64 \
  company-research-library-admin:latest

docker tag postgres:ecs-amd64 postgres:18.4-alpine

docker tag \
  nginxinc/nginx-unprivileged:ecs-amd64 \
  nginxinc/nginx-unprivileged:1.30.4-alpine

仓库现在用 scripts/build-ecs-image-bundle.sh 和 scripts/load-ecs-image-bundle.sh 固化了这套流程。

八、Compose 启动失败：CORS 配置触发应用自检

8.1 启动命令

ECS 已经有完整本地镜像，启动时禁止构建和拉取：

cd /srv/company/app

docker compose \
  --env-file /srv/company/secrets/company.env \
  up -d \
  --no-build \
  --pull never

--no-build 禁止 Compose 在服务器构建镜像。--pull never 禁止访问镜像仓库。

8.2 症状

PostgreSQL、Web、Admin 均变为 healthy，API 一直 unhealthy，edge 因依赖 API 健康状态而没有正常启动。

查看状态和日志：

docker compose \
  --env-file /srv/company/secrets/company.env \
  ps -a

docker compose \
  --env-file /srv/company/secrets/company.env \
  logs --no-color --tail=200 api

日志中的核心错误为：

ValidationError: cors_origins
CORS origins must use approved local development URLs

8.3 原因与处理

项目当前没有管理员登录系统。后端配置故意只接受批准的本地开发来源，防止开发阶段把未认证写接口当成公网能力。环境文件最初写入了 https://www.ayaseeri.com，应用因此主动拒绝启动。

改回批准的本地来源：

sed -i \
  's#^CORS_ORIGINS=.*#CORS_ORIGINS=http://localhost:3000,http://localhost:5173#' \
  /srv/company/secrets/company.env

然后重新创建 API：

docker compose \
  --env-file /srv/company/secrets/company.env \
  up -d \
  --no-build \
  --pull never

管理端通过 SSH 隧道访问同一个 edge 地址，浏览器请求与 API 同源，因此不依赖公网 CORS。

健康检查全部通过：

curl --fail http://127.0.0.1:8080/healthz
curl --fail http://127.0.0.1:8080/api/health/live
curl --fail http://127.0.0.1:8080/api/health/ready

对应输出为 ok、live 和 ready。

九、Nginx 不在 /etc/nginx

9.1 错误假设

最初按 RPM 安装布局尝试备份：

cp -a /etc/nginx \
  /etc/nginx.backup-$(date +%Y%m%d-%H%M%S)

命令返回：

cp: cannot stat '/etc/nginx': No such file or directory

nginx -t 已经给出线索：

the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok

服务器使用源码安装的 Nginx，主目录是 /usr/local/nginx。

9.2 查清配置、进程和证书

find /usr/local/nginx/conf \
  -maxdepth 3 \
  -type f \
  -print

grep -RInE \
  'include|server_name|listen|ssl_certificate|proxy_pass' \
  /usr/local/nginx/conf

systemctl status nginx --no-pager -l 2>&1

ps -ef | grep '[n]ginx'

find /usr/local/nginx \
  -maxdepth 5 \
  -type f \
  \( -name '*.pem' -o -name '*.crt' -o -name '*.cer' -o -name '*.key' \) \
  -print

这些命令确认了三件事：

• 配置文件只有 /usr/local/nginx/conf/nginx.conf。
• Nginx 由手工命令启动，没有 nginx.service。
• 旧证书位于 /usr/local/nginx/conf/cert/。

ps 同时显示宿主机 Nginx 和容器内 Nginx。宿主机 master 由 root 启动；容器进程使用容器 UID，并带有 daemon off 参数。排查时不能看到多个 Nginx 进程就全部终止。

正确备份方式为：

cp -a /usr/local/nginx/conf \
  /usr/local/nginx/conf.backup-$(date +%Y%m%d-%H%M%S)

十、设计公网只读边界

宿主机 Nginx 只代理回环地址 127.0.0.1:8080。公网管理端直接返回 404：

location = /admin {
    return 404;
}

location ^~ /admin/ {
    return 404;
}

API 只允许读取和预检：

location ^~ /api/ {
    limit_except GET HEAD OPTIONS {
        deny all;
    }

    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

公开页面继续代理：

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

每次修改都先测试再重载：

nginx -t && nginx -s reload

nginx -t 检查语法、证书文件和引用路径。只有前半段成功，Shell 才会执行 nginx -s reload。

验证结果：

curl -I -H 'Host: www.ayaseeri.com' \
  http://127.0.0.1/

curl -s -o /dev/null -w 'admin: %{http_code}\n' \
  -H 'Host: www.ayaseeri.com' \
  http://127.0.0.1/admin/

首页返回 200，管理端返回 404。

最终配置保存在 infra/aliyun-ecs/nginx.conf。

十一、旧证书过期与 Certbot 续签

11.1 检查旧证书

openssl x509 \
  -in /usr/local/nginx/conf/cert/www.ayaseeri.com.pem \
  -noout \
  -subject \
  -issuer \
  -dates \
  -ext subjectAltName

旧证书同时包含 ayaseeri.com 和 www.ayaseeri.com，到期时间为 2026-06-30。部署日期为 2026-07-21，证书已经失效。

11.2 检查 DNS 和 HTTP 验证路径

阿里云 DNS 使用 A 记录把域名指向 IPv4 地址。阿里云 DNS 网站解析指南

getent ahostsv4 ayaseeri.com
getent ahostsv4 www.ayaseeri.com

两个域名都解析到同一台 ECS 后，创建 webroot 验证目录：

mkdir -p /var/www/letsencrypt/.well-known/acme-challenge
chmod -R 755 /var/www/letsencrypt

echo 'acme-check-ok' \
  > /var/www/letsencrypt/.well-known/acme-challenge/check

curl --fail \
  http://ayaseeri.com/.well-known/acme-challenge/check

curl --fail \
  http://www.ayaseeri.com/.well-known/acme-challenge/check

Certbot 的 webroot 验证要求服务器能从公网通过 80 端口提供 HTTP 站点；官方也建议用 certbot renew --dry-run 测试自动续签。Certbot Nginx 指南

11.3 DNF 被 Ctrl+Z 暂停

安装 Certbot 时误按 Ctrl+Z：

[1]+ Stopped dnf install -y certbot

再次运行 DNF 后，新进程一直等待旧进程释放锁：

Waiting for process with pid ... to finish

Ctrl+Z 会暂停前台进程并把它留在作业表中。它不会像 Ctrl+C 那样终止进程。恢复方法：

jobs -l
fg %1

jobs -l 列出当前 Shell 的作业和 PID，fg %1 把编号 1 的暂停作业恢复到前台。若创建了第二个重复作业，先用 Ctrl+C 停止等待命令，再处理暂停作业。

11.4 申请新证书

dnf install -y epel-release certbot

certbot certonly \
  --webroot \
  --webroot-path /var/www/letsencrypt \
  --cert-name ayaseeri.com \
  -d ayaseeri.com \
  -d www.ayaseeri.com

使用 certonly --webroot 的原因是服务器运行自定义路径的源码 Nginx。Certbot 只申请证书，不改写 /usr/local/nginx/conf/nginx.conf。

新文件位于：

/etc/letsencrypt/live/ayaseeri.com/fullchain.pem
/etc/letsencrypt/live/ayaseeri.com/privkey.pem

修改 Nginx 的证书路径并重载：

nginx -t && nginx -s reload

检查 Nginx 实际提供的证书：

openssl s_client \
  -connect 127.0.0.1:443 \
  -servername www.ayaseeri.com \
  </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

新证书到期时间为 2026-10-19，根域名和 www 均返回 HTTPS 200。

11.5 自动续签与重载

Certbot 会更新软链接指向的证书文件，但 Nginx 需要重载后才会使用新证书。部署钩子内容为：

#!/bin/sh
set -eu

/usr/local/nginx/sbin/nginx -t
/usr/local/nginx/sbin/nginx -s reload

安装、测试并启用定时器：

install -m 750 reload-nginx.sh \
  /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

certbot renew --dry-run

systemctl enable --now certbot-renew.timer
systemctl list-timers --all | grep -i certbot

模拟续签返回 all simulated renewals succeeded。

十二、把手工 Nginx 纳入 systemd

源码安装的 Nginx 由手工命令启动，系统重启后不会恢复。本次创建了 /etc/systemd/system/nginx.service：

[Unit]
Description=NGINX HTTP and reverse proxy server
After=network-online.target docker.service
Wants=network-online.target

[Service]
Type=forking
PIDFile=/usr/local/nginx/logs/nginx.pid
ExecStartPre=/usr/local/nginx/sbin/nginx -t -q
ExecStart=/usr/local/nginx/sbin/nginx
ExecReload=/usr/local/nginx/sbin/nginx -s reload
ExecStop=/usr/local/nginx/sbin/nginx -s quit
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

切换过程：

systemctl daemon-reload
systemctl enable nginx
nginx -s quit
sleep 2
systemctl start nginx

nginx -s quit 让旧 master 完成已有请求后退出。systemctl start nginx 再由 systemd 启动新 master。

验证：

systemctl is-enabled nginx
systemctl is-active nginx
systemctl status nginx --no-pager -l

curl -I https://www.ayaseeri.com/
curl -I http://www.ayaseeri.com/

结果为 enabled、active、HTTPS 200、HTTP 301。

十三、通过 SSH 隧道访问管理端

Mac 另开终端：

ssh -N \
  -L 18080:127.0.0.1:8080 \
  root@<ECS-IP>

参数含义：

• -N 表示不执行远端 Shell 命令，只建立转发。
• -L 本地端口:远端目标:远端端口 把 Mac 的 18080 转发到 ECS 回环地址的 8080。

浏览器访问：

http://127.0.0.1:18080/admin/

隧道内管理端正常显示。公网访问下面的地址返回 404：

https://www.ayaseeri.com/admin/

这个方案保留了未认证管理端的本地边界，也免去了把 8080 加入安全组。

十四、完整业务验收

管理端创建“贵州茅台”，填写证券代码和市场，再上传两种资料：

doc/snapshots/published/贵州茅台.html
doc/snapshots/sources/贵州茅台.md

公开首页出现公司和资料目录。HTML 直接嵌入；Markdown 使用统一模板生成 HTML 后嵌入。

数据库检查：

docker compose \
  --env-file /srv/company/secrets/company.env \
  exec -T postgres sh -lc \
  'psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -c "SELECT name, ticker, market FROM companies ORDER BY created_at;"'

文档索引检查：

docker compose \
  --env-file /srv/company/secrets/company.env \
  exec -T postgres sh -lc \
  'psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -c "SELECT title, format, original_filename FROM documents ORDER BY uploaded_at;"'

内容文件检查：

docker compose \
  --env-file /srv/company/secrets/company.env \
  exec -T api sh -lc \
  'find /data/content -maxdepth 4 -type f | sort'

HTML 目录包含 source.html。Markdown 目录包含 source.md 和 rendered.html。

十五、备份数据库和内容卷

Docker 容器可以重建，命名卷中的数据库和资料不能跟随镜像恢复。Docker 文档也区分镜像和卷：保存镜像不会包含卷数据。Docker 数据持久化

本项目必须把 PostgreSQL 索引和内容卷放入同一个备份集。备份脚本执行以下步骤：

1. 使用文件锁防止两个任务重叠。
2. 暂停 API，阻止备份期间写入。
3. 用 pg_dump -Fc 导出数据库。
4. 把内容卷压缩为 content.tar.gz。
5. 使用 pg_restore --list、tar -tzf 和 SHA-256 检查备份。
6. 恢复 API，更新 latest 软链接并清理 30 天前的目录。

PostgreSQL 官方文档说明 pg_dump 能生成一致导出，custom 格式 -Fc 适合交给 pg_restore 检查和恢复。PostgreSQL 18 pg_dump

核心数据库命令：

docker compose \
  --env-file /srv/company/secrets/company.env \
  exec -T postgres sh -lc \
  'exec pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB" -Fc' \
  > postgres.dump

核心内容卷命令：

docker run --rm --pull never \
  --user 0:0 \
  -v company-research-library_content_data:/data:ro \
  nginxinc/nginx-unprivileged:1.30.4-alpine \
  tar -czf - -C /data . \
  > content.tar.gz

完整实现位于 scripts/company-backup.sh。

每天凌晨 3:30 由 systemd timer 执行，并随机延迟最多 15 分钟：

[Timer]
OnCalendar=*-*-* 03:30:00
RandomizedDelaySec=15m
Persistent=true
Unit=company-backup.service

启用和检查：

systemctl daemon-reload
systemctl enable --now company-backup.timer
systemctl list-timers --all | grep company-backup
journalctl -u company-backup.service --no-pager -n 100

首次备份生成：

postgres.dump
content.tar.gz
SHA256SUMS
created-at.txt
compose-status.txt

本轮按使用者决定只保留 ECS 本地备份。它可以处理误删和应用故障，无法处理整台 ECS 或云盘损坏。资料规模增加后应复制到 OSS 或另一台机器。

十六、问题与解决方案总表

十七、这次部署留下的经验

17.1 先查现场，再写配置

nginx -t 已经打印真实配置路径。若先看这条输出，就不会尝试备份不存在的 /etc/nginx。服务器上的安装来源、目录和启动方式不能靠习惯推断。

17.2 镜像可用性包含网络和架构

镜像标签存在不代表 ECS 能获得可执行镜像。部署前要确认仓库可达、标签存在、目标架构匹配、归档完整。docker image inspect、gzip -t 和 SHA-256 分别覆盖这三个检查点。

17.3 应用自检能阻止危险配置

FastAPI 因公网 CORS 值拒绝启动，看起来像部署故障，实质上保护了未认证写接口。修复时保留了安全边界，没有删除验证器。

17.4 管理端认证可以分阶段实现

当前阶段用 SSH 隧道限制管理端范围，公开站点已经可用。以后实现登录、授权和 CSRF 后，再评估是否开放公网管理入口。

17.5 备份需要同时覆盖索引和文件

数据库知道文档位置，内容卷保存文档正文。只备份其中一边会产生无法读取的索引或没有索引的孤立文件。备份脚本暂停写入，并把两边放入同一个时间戳目录。

十八、当前运维清单

检查服务：

docker compose \
  --env-file /srv/company/secrets/company.env \
  -f /srv/company/app/compose.yaml ps

systemctl is-active docker
systemctl is-active nginx
systemctl --failed

检查网站：

curl --fail https://www.ayaseeri.com/ > /dev/null

curl -s -o /dev/null -w '%{http_code}\n' \
  https://www.ayaseeri.com/admin/

第二条必须返回 404。

检查定时任务和磁盘：

systemctl list-timers --all \
  | grep -E 'company-backup|certbot'

df -h /
docker system df

查看应用日志：

docker compose \
  --env-file /srv/company/secrets/company.env \
  -f /srv/company/app/compose.yaml \
  logs --no-color --tail=200 api edge

十九、仓库中固化的资产

本轮对话结束前，服务器上的手工配置被整理进仓库：

仓库测试会检查这些资产存在、Nginx 拦截管理端和写方法、脚本没有写入固定 ECS IP 或密码。两份 Nginx 配置也使用真实 Nginx 1.30.4 镜像执行过 nginx -t。

参考资料

1. Docker Engine on CentOS
2. Install the Docker Compose plugin
3. 阿里云 Docker CE 镜像
4. 阿里云 ECS 安装和使用 Docker
5. 阿里云 ACR 配置镜像加速器
6. Docker 多平台构建
7. docker buildx build
8. docker image save
9. Docker 数据持久化
10. 阿里云 ECS 安全组指南
11. 阿里云 DNS 网站解析指南
12. Certbot Nginx 指南
13. PostgreSQL 18 pg_dump

结语

这次部署没有依赖一条从头跑到尾的理想命令。每个失败都留下了可检查的证据：DNF 的目标域名、Docker manifest、镜像架构、FastAPI 验证错误、Nginx 编译路径、证书日期、systemd 状态和备份校验值。处理顺序始终相同：读取错误，缩小范围，修改一个变量，再用健康检查确认结果。

公开站点已经具备稳定的只读入口，管理端仍停留在 SSH 隧道内。下一阶段若要开放公网管理，应先实现管理员认证、会话、授权和 CSRF 防护。现有部署边界可以继续承载资料录入和公开阅读。

记录时间：2026-07-20 16:39:46

这篇笔记来自对当前 Codex 配置、插件清单、技能目录和本轮实际可用能力的一次盘点。

先说明「使用频率」怎么算

Codex 没有向我提供一份可信的 Skill 调用次数统计。因此，下面的「高频、中频、低频或专项」不是历史调用排行榜，而是根据三件事作出的实用分级：触发范围有多广、与我当前的写作及开发流程有多接近、日常任务遇到它的概率有多大。

本次确认到 15 个当前可用的 Plugins。其中 13 个明确写在本机 Codex 配置中并处于启用状态，GitHub 与 Gmail 则作为当前会话可用的连接器插件出现。插件内部带有的 Skills 全部放在对应插件下面，不再进入后面的独立 Skills 清单。

Plugins：高频

1. Superpowers

它是一套贯穿软件开发全过程的方法库，也是覆盖面最广的插件。它规定如何澄清需求、写计划、测试、调试、审查和交付。

插件内含 14 个 Skills：

• using-superpowers：每轮任务开始时先判断应该调用哪些 Skills。
• brainstorming：在写代码前澄清目标、约束、成功标准与方案取舍。
• writing-plans：把已经确认的规格拆成可以逐步执行的实现计划。
• executing-plans：按现成计划分阶段实施，并在检查点复核结果。
• test-driven-development：先写失败测试，再写最少实现，最后整理代码。
• systematic-debugging：从复现、证据和根因入手处理 Bug 与异常结果。
• verification-before-completion：在声称完成以前重新运行验证命令，用输出证明结果。
• requesting-code-review：完成重要改动后发起独立代码审查。
• receiving-code-review：先验证审查意见的技术正确性，再决定如何修改。
• finishing-a-development-branch：在功能完成后整理合并、PR 或分支清理步骤。
• using-git-worktrees：用 Git Worktree 隔离功能开发，减少对当前工作区的干扰。
• dispatching-parallel-agents：把互不依赖的任务交给多个代理并行处理。
• subagent-driven-development：让子代理按任务块实现，并穿插规格与质量审查。
• writing-skills：创建、修改和验证 Skill 本身。

2. GitHub

用于读取仓库、Issue、Pull Request 与评论，也能结合本地 git 和 gh 完成发布、审查与 CI 修复。

插件内含 4 个 Skills：

• github：GitHub 任务的总入口，负责仓库、Issue 和 PR 的查询与分流。
• gh-address-comments：读取未解决的 PR 审查线程，落实选定的修改意见。
• gh-fix-ci：检查 GitHub Actions 失败日志，定位原因并修复 CI。
• yeet：确认改动范围后创建分支、提交、推送并打开 Draft PR。

3. Browser

插件内的 control-in-app-browser 用于控制 Codex 内置浏览器。它可以打开本地页面、点击、输入、截图和检查交互状态，尤其适合前端完成后的本地验收。

4. Computer Use

插件内的 computer-use 通过 macOS 图形界面操作本机应用。终端、API 或专用连接器无法完成任务时，它可以读取窗口、点击控件和输入内容。

5. Frontend Design

插件内的 frontend-design 用于设计或重塑前端界面。它关注视觉方向、字体、布局、层级和产品气质，帮助页面摆脱默认模板感。

Plugins：中频

6. Chrome

插件内的 control-chrome 操作我已经登录的 Chrome，包括现有标签页、Cookie、扩展和登录状态。需要使用真实账户环境时，它比新的无状态浏览器更合适。

7. Sites

这是 OpenAI 的网站构建与托管插件。它只在带有 .openai/hosting.json 的 Sites 项目中强制使用。

• sites-building：构建网站、仪表盘、作品集、门户和内部工具。
• sites-hosting：发布网站并管理 Sites 托管状态。

8. Visualize

插件内的 visualize 用于在对话中制作交互式图表、地图、流程图、模拟器、数据探索器和 3D 模型。需要「看见并调节」一个概念时，它比纯文字解释更有效。

9. Documents

插件内的 documents 用于创建、编辑、批注和红线修改 .docx。它要求把文档渲染成页面图片做视觉检查，适合正式 Word 文档。

10. PDF

插件内的 pdf 读取、生成、拆分、合并和检查 PDF，并通过页面渲染确认文字、分页与版式没有出错。

11. Spreadsheets

用于创建、分析和验证 Excel 或 Google Sheets 兼容工作簿。

• Spreadsheets：处理独立的 .xlsx、.xls、.csv 与 .tsv 文件。
• excel-live-control：通过 Excel 加载项控制正在打开的工作簿与活动会话。

12. Gmail

用于搜索邮箱、阅读邮件线程、提取行动项和起草回复。发送、归档、删除或修改标签等动作仍需要明确意图。

• gmail：邮箱搜索、线程摘要、回复草稿、转发与邮件整理的总入口。
• gmail-inbox-triage：把收件箱分成紧急、需要回复、等待中与仅供了解等队列。

Plugins：低频或专项

13. Presentations

插件内的 Presentations 用于创建、编辑、渲染和导出 PowerPoint 或 Google Slides 演示文稿。只有需要正式幻灯片产物时才会触发。

14. Template Creator

插件内的 template-creator 从现有 Word、PowerPoint 或 Excel 文件制作可复用的个人模板 Skill。它服务于长期重复使用的版式，不负责普通的一次性文档。

15. Skill Creator

插件内的 skill-creator 用于创建或改进 Skills，并通过评测、基准测试与方差分析检查效果。Codex 还带有一个同名的系统 Skill，提供创建 Skill 的基础规范；两者用途重叠，所以统一放在这里说明，不在独立清单重复列出。

独立 Skills：高频

1. publish-diary-note

把当前讨论整理成符合 mewmoire 约定的 Markdown 日记，取得真实时间，生成四字段 Frontmatter，然后构建并发布到 Cloudflare Pages。这篇文章正在使用它。

2. publish-article

把网页、粘贴内容、主题简报、本地笔记或当前对话改写成中文文章，并发布到同一个 Eleventy 日记站。它更适合有明确来源、需要翻译或改编的长文。

3. stop-slop

清理 AI 写作痕迹：删除空话、套路式对照、机械排比、虚假强调和过度解释，让文字更直接、更像真实作者。

4. agent-reach

负责互联网检索与研究。它把搜索分发到合适渠道，适合查新闻、论文、社交平台讨论、代码资料和其他会随时间变化的信息。

5. cloudflare

Cloudflare 平台的总入口，覆盖 Workers、Pages、KV、D1、R2、AI、Vectorize、网络、安全与基础设施即代码。当前站点部署在 Cloudflare Pages，因此使用机会较多。

6. wrangler

在运行 Wrangler CLI 前提供正确命令和操作规范，用于开发、部署和管理 Workers、Pages、D1、R2、KV、Queues、Workflows 等资源。

7. workers-best-practices

编写或审查 Cloudflare Workers 时检查生产实践，包括流式响应、悬空 Promise、全局可变状态、Secrets、Bindings 与可观测性。

8. openai-docs

回答 OpenAI API、模型、Codex 与提示词升级问题时，优先读取最新官方文档并给出引用，避免依赖已经过期的记忆。

独立 Skills：中频

9. imagegen

生成或编辑位图资产，包括照片、插画、纹理、透明背景素材、产品图和 UI Mockup。普通图片任务默认调用内置图像生成工具。

10. web-perf

用 Chrome DevTools 分析 LCP、INP、CLS、FCP、TBT、缓存、网络依赖和布局偏移，适合网站速度与 Core Web Vitals 优化。

11. agents-sdk

在 Cloudflare Workers 上构建有状态 AI Agent、WebSocket 应用、定时任务、工作流、MCP Server 与语音代理。

12. durable-objects

设计和审查 Durable Objects，适合聊天室、多人协作、预订系统、SQLite 状态、Alarms 与 WebSocket 协调。

13. chatgpt-apps

构建 ChatGPT Apps SDK 项目，把 MCP Server 与 Widget UI 连接起来，并处理资源注册、Bridge、CSP、Domain 和兼容性配置。

14. find-skills

当我想知道「有没有一个 Skill 能做某件事」时，用它搜索可安装能力并给出安装方向。

15. skill-installer

从 OpenAI 的 curated 或 experimental 清单，以及公开或私有 GitHub 仓库，把 Skill 安装到 $CODEX_HOME/skills。

16. plugin-creator

创建 Codex Plugin 的目录、.codex-plugin/plugin.json、可选结构和个人 Marketplace 条目，也负责开发期间的重新安装流程。

独立 Skills：低频或专项

17. cloudflare-email-service

为 Workers 或其他应用接入 Cloudflare Email Sending 与 Email Routing，并处理 SPF、DKIM、DMARC 和投递问题。

18. cloudflare-one

处理 Cloudflare One、Zero Trust 与 SASE，包括 Access、Gateway、WARP、Tunnel、DLP、CASB、设备姿态和身份系统。

19. cloudflare-one-migrations

把 Zscaler、Palo Alto、传统 VPN、SWG 或其他 SASE 架构迁移到 Cloudflare One，负责差距分析、策略映射和分阶段上线计划。

20. sandbox-sdk

构建安全执行不受信任代码的应用，例如代码解释器、在线开发环境、AI 执行器和 CI/CD 隔离环境。

21. turnstile-spin

端到端配置 Cloudflare Turnstile：创建 Widget、部署 siteverify Worker、接入前端、验证结果并保存可复用配置。

22. hk-value-snapshot

用真实财报与行情数据为港股公司生成「价值线企业快照版」，同时输出 HTML 与 Markdown，适合三十秒基本面筛选和价值投资研究。

23. review-agent

这是系统内置、主要供审查代理调用的只读 Skill。它检查指定 Diff、Commit 或分支变化，按严重度报告可执行缺陷，不直接修改代码。

缓存不等于已经安装

本机插件缓存中还能看到 openai-templates、build-web-apps、build-ios-apps、build-macos-apps 和 expo 等目录，也有不同来源的 superpowers 副本。它们没有出现在当前启用配置或本轮可用插件清单中，因此这次没有把它们列为已安装插件。

以后再次盘点时，应继续以三类证据交叉确认：Codex 的启用配置、本轮暴露的 Skills 与连接器、磁盘上的实际 Skill 文件。只看缓存目录，很容易把下载过、暂存过或已经停用的插件误算成当前工具。

记录时间：2026-07-20 13:31:12

这篇笔记整理自一次关于「做事前总是犹豫不决」的讨论。它不是心理诊断，只是对一种反复出现的思维与行动模式的梳理。

十秒钟的事情，为什么会拖上半小时

请假、提交报告、回复一条消息，都没有多少技术难度，后果通常也可控。可我仍会在行动以前反复推演：会不会影响别人？领导会怎么看我？这句话是否足够得体？要不要再等一会儿？

大脑在行动前启动的漫长风险评估，才真正消耗时间。

这套流程里混合了几种熟悉的倾向：在意别人的评价，习惯反刍，担心决定留下不可逆的后果，也希望找到最正确的表达和做法。它们叠加在一起，一件小事便有了远超实际的分量。

我拥有行动能力，只是把太多精力花在了避免犯错、预测反应和消除不确定性上。

我想在行动前得到确定性

犹豫背后藏着一个很高的要求：做以前便知道结果，说以前便知道别人会怎么想，决定以前便确认自己不会后悔。

现实无法提供这种确定性。只要我仍把「完全确定」当成行动条件，大脑就总能提出下一个问题。

于是，分析形成了一条循环：

遇到事情

→ 感到焦虑

→ 继续分析与修改

→ 暂时获得一点控制感

→ 仍然没有行动

→ 事情在心里变得更重

→ 更加焦虑。

分析本来应该帮助我作出决定，但在这条循环里，它承担了缓解焦虑的作用。只要继续想，我便暂时不用面对提交以后那一点无法控制的结果。

这也解释了为什么想得越久，不一定越清楚。有些思考并没有增加新信息，只是在重复同一种担心。

我担心的常常是别人的评价

请假时，我可能担心领导觉得自己态度不好；回复消息时，我可能担心对方觉得自己表达不妥；提出需求时，我又怕给别人添麻烦。

表面上，我在判断一件事是否合理。心里真正等待确认的，往往是：

别人会不会因为我的行为，对我产生负面评价？

当我试图预先照顾每个人的感受，也就把本来属于别人的判断揽到了自己身上。我既要替自己作决定，还想替对方完成反应和评价，当然很难轻松行动。

负责并不等于消除所有人的不满。我的责任是提供必要信息、尊重规则、承担自己能够预见的后果。对方如何理解和回应，则需要留给对方。

寻找最优解，在生活里可能变成负担

我喜欢寻找规律、研究简便方法，也习惯比较不同方案。这种能力在技术、学习和投资中很有用，因为许多问题确实值得推演。

生活里的大量小决定却没有唯一最优解。请假申请写得更漂亮一点，通常不会显著改变结果；一条普通消息改到第五遍，也未必比第一遍更真诚。

如果我把每件事都当成一道必须求出最优解的题，思考成本很快就会超过错误本身的成本。

我需要先区分决定的类型：涉及健康、长期资金和不可逆承诺的事情，可以慢下来；普通消息、常规申请和低成本选择，只需要一个合格答案。

对后者来说，六十分足以开始。剩下的清晰感，要靠行动后的反馈补上。

先把脑子里的风险还原到现实

犹豫出现时，我可以先问：

如果这件事做错了，最坏会发生什么？

以请假为例，现实中的最坏情况可能只是领导多问一句原因，或者这次申请没有获批。接下来，我说明情况、调整安排或正常上班。事情有具体后果，也有对应动作。

焦虑则容易把「可能被问一句」扩大成「对方会否定我的工作态度」，再把一次评价连接到整段职业关系。脑子里的风险因此升到九十分，现实里的风险可能只有十分。

把最坏结果写成一句具体的话，再写下应对动作，可以阻止想象继续扩张：

1. 我具体担心什么？
2. 它发生的概率有多大？
3. 即使发生，我准备怎样处理？
4. 这件事值得我再想多久？

如果新的思考既没有带来信息，也没有改变动作，我就该结束这一轮分析。

用小事练习在不确定中行动

改变这种模式，不需要先消除焦虑。更实际的训练，是在后果可控的小事上带着一点不确定感行动：

• 消息写好以后，在三十秒内发出；
• 请假申请完成以后，只检查一次便提交；
• 买几十元的日用品，只比较有限的选项；
• 回复普通问题时，不反复删除和改写；
• 为低风险决定设置两分钟期限，到点便选择。

训练要积累一类新的经验：我没有完全想清楚，也完成了行动；结果即使不完美，我仍然可以处理。

每一次这样的小行动，都在练习对不确定性的耐受能力。次数多了，大脑会慢慢发现，行动以后出现的反馈通常比行动以前的想象更具体，也更容易应对。

衡量进步，不再只看决定是否正确

如果我只用结果评价自己，一次不理想的回应就会被解释为「当初果然不该行动」。这会重新强化犹豫。

更适合当前阶段的衡量方式是：我有没有在合理时间内完成决定？有没有控制投入的思考成本？结果出现以后，我能否根据事实调整？

未来一段时间，我不必追求做出更多完美决定。我可以先练习让低风险的小事更快落地，把分析留给真正重要的问题。

很多清晰感需要行动带来的反馈。先向前走一步，我才会拿到下一条信息。

记录时间：2026-07-17 20:26:23

这篇笔记整理自一次关于「独立开发者如何使用 AI 从 Idea 走到产品上线」的长讨论。

真正的问题不是缺少 Skills

独立开发者懂工程，也能让 AI 快速生成代码。麻烦恰恰来自这种能力：用户问题还没有说清楚，脑中已经开始排列 Nuxt、Flutter、FastAPI、PostgreSQL、Docker 和云服务。

工程进展很具体，容易让人产生项目正在前进的感觉。但如果产品定位错了，完整的架构只会提高改方向的成本。

适合我的纪律是：

产品探索阶段不讨论实现；静态原型阶段不建设生产架构；工程阶段不增加 MVP 之外的需求；发布阶段不绕过测试、备份和回滚。

整个流程只分成三条线：

新项目：问题探索 → 产品规格 → 静态原型 → 冻结 MVP → 技术方案

每个功能：轻量规格 → 计划 → 实现与测试 → 独立审查 → 人工验收

每次发布：Staging → E2E → 人工批准 → 生产部署 → Smoke Test

一、产品探索：先证明问题存在

我的输入

• 产品 Idea；
• 我认为的目标用户；
• 用户现在使用的替代方案；
• 三至五个真实案例或访谈记录。

Skill + Prompt

brainstorming 是可选项。直接使用下面的 Prompt 也足够：

你现在是产品探索顾问，不是技术负责人。

请帮我确认：
1. 目标用户是谁；
2. 用户在什么场景遇到问题；
3. 用户目前怎样解决；
4. 现有方法哪里不够好；
5. 问题的频率和严重程度；
6. 最关键的价值假设是什么；
7. 如何用最低成本验证这个假设。

禁止讨论技术栈、页面实现、数据库、API、架构和部署。
当我开始讨论实现时，提醒我回到用户问题。

AI 做什么

AI 帮我整理假设、指出证据缺口、设计访谈或原型验证方法。它不能替我证明需求存在，也不能用竞品功能清单代替用户证据。

输出什么

结果：docs/product/problem.md

文档只需要写清：目标用户、具体场景、当前做法、核心障碍、价值假设和验证计划。

通过条件是一句没有技术名词的问题定义：

某类用户在某个场景下，因为某个障碍，无法完成某个重要目标。

二、产品设计：把问题变成可体验的流程

我的输入

• 已验证的问题定义；
• 用户最重要的一项任务；
• 第一版要验证的价值；
• 明确不做的功能。

Skill + Prompt

先用 speckit-specify 起草产品规格，再用 speckit-clarify 消除歧义：

speckit-specify：
根据已经确认的用户问题定义 MVP。
只描述目标用户、核心任务、用户流程、产品行为、异常场景、
验收标准和明确非范围。禁止讨论数据库、API、框架和部署。
优先删减功能。

speckit-clarify：
检查当前规格中存在多种解释的地方。
重点澄清内容组织、排序筛选、空状态、错误状态、发布下架行为
以及第一版明确不做的能力。把决定更新回规格，仍不讨论实现。

接着用 frontend-design 制作静态原型。数据可以写死，不连接 API，不建立数据库。页面完成后再用 web-design-guidelines 检查语义化 HTML、键盘操作、对比度、响应式、表单标签和长文阅读体验。

AI 做什么

AI 把产品行为整理成用户故事和验收标准，再把规格变成可以点击的页面。此时的原型用于验证信息架构、页面顺序和阅读体验，不承担生产代码的职责。

输出什么

结果：

specs/001-mvp/spec.md
docs/product/user-flow.md
docs/product/mvp.md
prototype/
docs/product/prototype-review.md

只有当目标用户能通过原型完成核心任务，并且 MVP 已经写清「必须做」和「明确不做」，项目才进入工程阶段。

三、工程设计：让技术服务已确认的产品

我的输入

• 冻结的 MVP；
• 已验证的静态原型；
• 技术和预算约束；
• 已有内容样本；
• 部署环境限制。

Skill + Prompt

使用 speckit-plan：

产品问题、用户流程、原型和 MVP 已经批准。

请设计满足现有规格的最简单实现方案。
每个技术决策都要注明它解决了哪条产品需求。
不得增加 MVP 之外的功能，不为尚未出现的规模问题设计架构。

输出模块边界、数据模型、API 契约、认证、测试、部署、备份、
回滚、当前不需要的基础设施，以及可以延后决定的问题。

投资内容平台还需要一个项目级 content-package-contract Skill，统一财报、CEO 演讲和管理层访谈的输出：

manifest.json
content.html
content.json
assets/
source/

契约应包含 JSON Schema、版本号、校验脚本和安全 HTML 白名单。网站、管理端和 App 从同一份契约读取内容，避免三个客户端各自猜测格式。

AI 做什么

AI 设计模块化单体、数据与接口契约、测试策略和部署路径，然后按用户可感知的能力拆成垂直切片。它不应该按「先做完数据库、再做完 API、最后做页面」分层拆任务。

输出什么

结果：

docs/architecture.md
docs/data-model.md
openapi.yaml
packages/content-contract/schema.json
scripts/validate_content_package.py
specs/001-mvp/tasks.md

第一个里程碑只打通一条闭环：生成一篇内容，后台导入和预览，发布后网站与 App 都能打开。

四、每个功能：固定使用一条短循环

我的输入

每次只给 AI 一个功能：用户要完成什么、验收标准、非范围、对应原型，以及允许修改的模块。

Skill + Prompt

writing-plans：
阅读 AGENTS.md、功能规格和相关代码，为当前功能写一份短计划。
逐步列出修改文件和验证方法，不加入规格之外的工作。

test-driven-development：
先写关键失败场景测试，确认测试失败，再写最小实现。
数据库变化使用迁移，API 变化同步契约，不做无关重构。

verification-before-completion：
实际运行测试、静态检查、类型检查和构建。
逐项核对验收标准，查看 Git Diff，并报告未覆盖风险。

出现失败时才调用 systematic-debugging。它要求先稳定复现、收集证据、一次验证一个假设，修复后补回归测试。

AI 做什么

AI 阅读规则，完成当前切片，运行验证并给出人工测试步骤。它不能自动推送或部署，也不能在编码过程中顺手扩张需求。

输出什么

**结果：**功能代码、测试、数据库迁移、更新后的 API 契约、真实命令结果、验收标准核对表和人工测试步骤。

编码完成后，打开一个新会话使用 requesting-code-review。审查者只读取规格、Diff 和测试结果，按 Blocker、High、Medium、Low 报告问题，不直接修改代码。修复后再次运行 verification-before-completion，最后由我亲自操作验收。

五、每次发布：测试环境与生产环境分开

我的输入

• Staging 地址和测试账号；
• 核心用户流程；
• 发布版本与 Git commit；
• 数据库备份状态；
• 当前生产镜像版本；
• 明确的发布批准。

Skill + Prompt

先用 agent-browser 在 Staging 完成登录、导入、预览、发布、公开浏览、移动端布局和下架流程。然后调用项目级 aliyun-release-checklist：

发布前检查 CI、迁移、备份、环境变量、域名、HTTPS、OSS 和回滚命令。
镜像使用 commit SHA，不使用 latest。

发布时推送镜像，ECS 拉取指定版本，执行迁移，更新容器，
检查 /health、首页、内容详情、管理端和静态资源。

任一步失败就停止，保存日志，恢复上一版本，并重新执行 Smoke Test。
未经我的明确确认，不得发布生产。

AI 做什么

AI 执行可自动化的检查，记录每一步证据，并在失败时停止。最终的 Go 或 No-Go 决定、数据库风险判断和生产发布批准仍由我负责。

输出什么

**结果：**Staging E2E 报告、截图、Go／No-Go 结论、发布记录、镜像版本、迁移结果、Smoke Test 结果和可执行的回滚命令。

最后保留哪些 Skills

核心 Skills：

speckit-specify
speckit-clarify
speckit-plan
frontend-design
web-design-guidelines
writing-plans
test-driven-development
systematic-debugging
verification-before-completion
requesting-code-review
finishing-a-development-branch
agent-browser

项目级 Skills：

content-package-contract
aliyun-release-checklist

brainstorming 和 speckit-tasks 按项目规模使用。using-git-worktrees、多 Agent 编排、复杂架构改造等工具，等并行任务和代码规模真的出现后再引入。

Skills 只是把工作方法固化下来。它们不能替代用户证据、产品取舍、亲自验收和生产发布前的判断。对独立开发者而言，最有价值的流程不是调用更多工具，而是在正确的阶段只解决一种问题。

记录时间：2026-07-17 20:26:02

这篇笔记整理自一次关于 Codex Skills、独立开发者工作流，以及如何避免过早思考架构的长对话。

真正的问题不是 Skills 不够多

讨论最初从「如何禁止 Codex 自动调用 Skills」开始，后来逐渐扩展到：从一个 Idea 出发，独立开发者如何借助 AI 完成产品、网站、管理后台、App、API、数据库、Docker 和云端发布。

过程中出现了许多 Skills，也产生了一个明显问题：每轮建议似乎都不一样。

原因并不复杂。不同 Skill 分别服务于产品探索、需求规格、界面设计、编码、调试、审查和发布。如果不先区分阶段，它们就会混成一条又长又重的流水线，让一个简单问题也经历头脑风暴、写计划、建 Worktree、TDD、代码审查和分支收尾。

对独立开发者而言，最大的风险通常不是不会写代码，而是：

工程能力太强，AI 执行速度太快，于是在用户问题还没有确定时，就开始设计数据库、API、Docker 和云服务。

这是一种「过早解决方案化」。架构越来越完整，产品价值却仍然模糊。

最合适的三阶段模型

整个项目只需要分成三个彼此隔离的阶段：

产品探索
→ 产品设计
→ 工程实现

每个阶段只解决一种问题，并设置清晰的进入条件。

第一阶段：产品探索

这一阶段只回答四个问题：

1. 谁遇到了问题？
2. 问题发生在什么具体场景？
3. 用户现在如何解决？
4. 现有方法为什么不够好？

输入： 产品 Idea、目标用户猜想、真实案例、现有替代方案。

AI 做什么： 追问用户、场景、频率、严重程度和行为改变的可能性，找出最关键的价值假设，并设计最低成本的验证方法。

可用 Skill： brainstorming。它不是必需品，一段明确限制讨论范围的 Prompt 也可以完成同样的工作。

输出： problem.md、待验证假设和验证计划。

阶段门禁： 必须能用一句话说清楚：某类用户在某个场景下，因为某个障碍，无法完成某个重要目标。

这一阶段禁止讨论技术栈、数据库、API、代码、Docker 和部署。想到的技术方案可以放进 parking-lot.md，但不进入当前决策。

第二阶段：产品设计

问题明确以后，才开始回答：用户如何通过产品完成任务？

输入： 已确认的问题、核心用户任务、第一版要验证的价值、明确不做的功能。

AI 做什么： 编写用户故事、核心流程、异常状态、验收标准和非范围；随后使用静态数据制作可点击原型。

可用 Skills：

• speckit-specify：把想法整理成产品规格，回答「做什么」。
• speckit-clarify：找出规格中的歧义，并把产品决定写回规格。
• frontend-design：把已确认的流程做成静态可体验原型。
• web-design-guidelines：审查已经存在的 UI 代码，不负责产品定位。

输出： spec.md、user-flow.md、mvp.md 和静态原型。

阶段门禁： 核心流程能在原型中完整走通，MVP 的「必须做」和「明确不做」已经冻结，并且自己或目标用户认可这个体验。

这一阶段仍然不建立真实数据库、API 和生产基础设施。静态原型的任务是验证价值与体验，不是偷偷开始写生产系统。

第三阶段：工程实现

只有用户问题、核心流程和 MVP 都被确认，才进入工程模式。

输入： 冻结的产品规格、已验证的原型、技术约束和真实内容样本。

AI 做什么： 设计满足当前需求的最小架构，定义数据与 API 契约，初始化工程，再把项目拆成可以独立验收的垂直切片。

可用 Skills：

• speckit-plan：把已确认的产品规格转换为技术方案。
• writing-plans：为一个明确功能写可执行的小步计划。
• test-driven-development：用于核心业务规则和 Bug 回归，不机械覆盖所有 UI 调整。
• systematic-debugging：出现异常时先复现、收集证据、验证假设，再修复根因。
• verification-before-completion：声称完成前实际运行测试、构建和检查。
• requesting-code-review：在独立上下文中根据规格、Diff 和测试结果找问题。
• finishing-a-development-branch：开发、审查和验收完成后整理 PR 与合并。

输出： 架构文档、数据契约、API 契约、可运行工程、功能代码、测试、迁移、审查报告和发布记录。

工程设计有一条硬约束：每个技术决策都必须能指向某条已经确认的产品需求。 不为尚未出现的规模问题建设微服务、消息队列或复杂平台。

先打通一条垂直闭环

不要先做完所有数据库，再做所有 API，最后才联调网站和 App。正确做法是先交付一条完整、可观察的用户能力。

对投资内容平台，第一条闭环应该是：

生成一篇财报、演讲或访谈内容
→ 管理后台导入
→ 系统校验和预览
→ 管理员发布
→ 网站能够阅读
→ App 能够阅读同一篇内容

这条闭环跑通以后，再增加公司管理、筛选、搜索、收藏或其他能力。系统是否成立，应由真实流程证明，而不是由目录数量和架构图证明。

每个功能的固定循环

每个功能不必重新走完整项目流程，只需要重复下面的小循环：

轻量功能规格
→ 简短实施计划
→ 实现与测试
→ 完成前验证
→ 新上下文审查 Diff
→ 人工验收
→ PR、CI、合并

你每次只输入：一个用户能力、验收标准、明确非范围和相关原型。

AI负责阅读项目规则、定位相关代码、写短计划、完成最小实现、运行验证，并报告仍未覆盖的风险。AI不应自行增加需求，也不应在未经允许时提交、推送或部署。

Bug 则使用更短的流程：

稳定复现
→ 找到根因
→ 写回归测试
→ 修复
→ 完整验证
→ 发布

每次发布的固定循环

部署 Staging
→ 真实浏览器与 App 流程测试
→ 人工批准
→ 数据库备份
→ 生产部署
→ Smoke Test
→ 观察日志和监控

浏览器端可以使用 agent-browser 或 Codex 的浏览器控制能力。阿里云发布流程更适合做成项目自己的 aliyun-release-checklist，其中固定检查镜像版本、数据库迁移、备份、ECS、OSS、域名、HTTPS、回滚命令和生产 Smoke Test。

另一个值得自建的 Skill 是 content-package-contract：它负责约束财报、CEO 演讲和管理层访谈采用相同的数据格式，使后台、网站和 App 面对的是同一个稳定输入。

Skills 应该怎样取舍

Skills 不是装得越多越好。重复能力只保留一套：

• brainstorming 与 grill-me 二选一；
• speckit-specify 可以替代通用的 to-prd；
• speckit-clarify 可以替代 grill-with-docs 的大部分作用；
• frontend-design 可以承担静态原型工作，不必再保留独立的 prototype；
• test-driven-development 与 tdd 二选一；
• 项目自己的 aliyun-release-checklist 替代通用发布清单。

Worktree、子 Agent、并行 Agent、架构优化和复杂诊断，都只在任务真的需要时使用。它们不是每个功能的固定仪式。

自动调用也要分类型

可以把 Skills 分成两类：

护栏型 Skills用于防止明显质量问题，例如 systematic-debugging 和 verification-before-completion，可以允许按需自动触发。

编排型 Skills会改变整个工作方式，例如 brainstorming、writing-plans、using-git-worktrees、test-driven-development 和多 Agent 开发，更适合手动调用。

希望保留手动调用、禁止隐式触发时，可以在对应 Skill 的 agents/openai.yaml 中设置：

policy:
  allow_implicit_invocation: false

如果某个 Skill 完全不需要，再在 Codex 配置中将它禁用。关键不是一刀切地禁止所有 Skills，而是避免让编排型 Skill 在不合适的阶段接管任务。

最后的极简版本

新项目只执行一次：

问题定义
→ 产品规格
→ 静态原型
→ 用户验证
→ 冻结 MVP
→ 最小技术设计
→ 第一条垂直闭环

每个功能重复：

轻量规格
→ 小步实现和测试
→ 独立 AI 审查
→ 人工验收
→ CI 合并

每次发布重复：

Staging
→ E2E
→ 人工批准
→ 备份和部署
→ Smoke Test
→ 监控

整套方法最终只剩下一条纪律：

产品探索阶段不讨论实现；静态原型阶段不建设生产架构；工程阶段不随意增加需求；发布阶段不绕过验证、备份和回滚。

记录时间：2026-07-15 13:17:38

愿景

成为一个更健康、更长寿、内心更平和、头脑更清醒、拥有更多选择自由的人。

使命

践行并传播价值投资与长期主义，通过技术、投资和真诚分享，帮助自己和他人做更少、更正确、更长期的选择。

价值观

本分

尊重规律，守住边界；做对的事，把事情做对；不占便宜，不推卸责任。

真诚

做真实的自己；正直坦荡，不卑不亢；不讨好，不伪装，也不欺骗自己。

理性

尊重事实，接受现实，独立思考；理解情绪，但不让情绪替自己作决定。

长期

尊重时间、复利和机会成本；专注少数重要的事，耐心积累，发现方向错误及时停止。

座右铭

做正确的事，把事情做对，剩下的交给时间。

Stop Doing List

一、投资

1. 不懂不投。 不能用简单语言说清商业模式、竞争优势、管理层和主要风险，不投资。

2. 不投坏生意。 不投长期缺乏竞争优势、定价权弱、盈利质量差、资本回报低的企业。

3. 不投脆弱的资产负债表。 不投依赖高杠杆才能生存、一次重大冲击就可能永久受损的企业。

4. 不与缺乏诚信的管理层合作。 管理层不诚实、不尊重股东、资本配置能力差，即使价格便宜也不投资。

5. 不用杠杆，不做空，不参与自己无法承受的风险。

6. 没有安全边际不买。 好企业不等于任何价格都值得买。

7. 不因股价、新闻、群聊和市场情绪频繁改变判断。

8. 不因沉没成本继续持有。 只判断从现在开始，它是否仍然值得持有。

二、人生

1. 不以捷径代替基本功。

2. 不以幻想、分析、规划或拖延回避现实。

3. 不占别人便宜，也不通过过度付出换取认可和关系。

4. 不推卸自己的责任，也不替别人承担本应由他承担的责任。

5. 不沉溺于抱怨、嫉妒、比较和受害者叙事。

6. 不复制别人的人生，不用他人的标准定义自己。

7. 不因沉没成本继续投入错误的人、项目和方向。

8. 不参与无助于目标的争论，不把注意力交给互联网情绪。

9. 不用输入代替输出，不把学习和准备误认为成果。

10. 不同时开启过多目标。每个阶段只保留一至两条核心主线。

11. 不透支健康换取短期成果。

12. 不把希望建立在对人性的理想化上。判断一个人，看行动、激励、边界和长期记录。

三、情感

1. 不长期单向付出。 不使用礼物、金钱、照顾和牺牲换取爱情。

2. 不向没有明确选择自己的人提供伴侣级投入。

3. 不把对等理解成逐笔算账。 对等看的是长期的选择、行动、时间、责任和关心。

4. 不在强烈情绪中作出重大决定。 先暂停，恢复平静后再处理。

5. 不读空气。 不用猜测代替直接沟通，不用言语暗示代替行动证据。

6. 不因害怕失去而隐藏真实需求，也不长期停留在模糊关系中。

7. 不把别人的回复速度、态度和选择当作自我价值的证明。

8. 不反刍没有新证据的过去。 复盘只为形成原则，形成原则以后停止重复审判自己。

9. 不试图通过改变、拯救或感动一个人，获得对方的选择。

10. 不因为认识时间长、投入很多或关系特殊，就忽视对方没有选择自己的事实。

记录时间：2026-07-14 16:14:16

这是一份关于职业转型、价值投资和 AI 工具化的下午日志。文中公司与财务数据用于研究方法验证，不构成投资建议。

起点：一次关于焦虑的对话

这件事的起点跟投资无关。

我是个移动端开发者，做电商 App。产品进入纯维护期以后，我已经半年没怎么写代码。就业环境不好，我一直觉得 AI 会取代我，而且对此有一种无能为力的感觉。

我把这份焦虑原封不动地丢给了 AI。它没有安慰我，而是指出了一个事实：真正的威胁不一定是 AI，而可能是这个岗位本身正在消亡。

与此同时，我手里其实握着一份难得的资源——一份还在发工资、但几乎不占用精力的工作。它等于给了我一条 6—12 个月的在职跑道，让我可以在不立刻失去现金流的情况下，尝试新的方向。

它给我的建议是：别再把主要精力放在框架细节上。那是贬值最快的部分。更值得做的是用 AI 把开发速度转化成产品能力，再把方向放在我两个能力圈的交叉点：我写了十年代码，也做了多年价值投资。

于是这个下午，我决定试一试。

第一步：搞清楚能做什么，以及不能做什么

我先做了一轮调研。几个关键结论很快把产品边界画了出来。

第一，合规是红线。 在国内，付费提供个股买卖建议属于证券投资咨询业务，个人开发者不能把“AI 荐股”当成产品方向。工具型产品则不同：数据、记录、复盘和研究辅助不直接替用户做交易决策。理杏仁这样的工具能够按年收费，说明这个需求本身真实存在。

第二，市场并不是没有缝隙。 AI 投研终端已经被同花顺、东方财富等大厂占据，个人开发者很难正面竞争。但 App Store 上“交易复盘”“持仓记录”这类小而专的独立应用，仍然有真实付费用户。问题是，它们几乎清一色服务短线交易者。

价值投资者的长周期决策记录与复盘，反而没有被认真服务。

第三，数据成本可以压得很低。 AKShare 免费覆盖 A 股、港股的行情和财报数据，东方财富的公开接口也能取到 F10 的大量信息。对一个个人开发者来说，数据成本接近于零，真正稀缺的是把数据转化成判断的流程。

产品方向于是定了下来：价值投资者的决策日志 + AI 复盘。 用户记录买入时的逻辑，每次财报发布后，系统自动对照：当初的逻辑有没有被新事实破坏？

这比提醒“股价涨了还是跌了”更接近长期投资真正需要的反馈。

第二步：验证数据管道能不能跑通

光有方向不够，还得证明数据链路确实能工作。这个下午，我实际验证了几件事。

• 从东方财富公开接口拉取茅台 12 年年报数据、分红历史和实时行情，交叉验证后全部对得上，算出的市值与接口返回值一致到个位。
• 摸清港股接口里的数据陷阱：财报是人民币，股息和股价是港元，三种币种混在同一张表里；股本和股息字段常常是当前值，而不是历史值；上市前优先股的会计处理，还可能让净资产显示为负数。
• 用真实数据生成了茅台和腾讯的“价值线式”单页报告，把原本分散的接口字段压成一张可以快速阅读的企业快照。

顺带还收获了一个洞察：茅台 2025 年报营收、净利双降，2026 年一季度毛利率跌破 90%。如果这个产品已经存在，这正是应该触发“逻辑体检”提醒的时刻。

产品需求不是凭空想出来的，而是被数据本身验证了：长期投资者需要的不是更多行情通知，而是有人提醒他回头检查自己的原始判断。

第三步：把大师的读法变成可执行的框架

这是今天最有意思的部分。

巴菲特说，他翻《价值线》30 秒就知道对一家公司有没有兴趣；芒格说，如果他开一所商学院，就会用《价值线》的图表教学。但他们到底在看什么？

我和 AI 把原始资料翻了一遍，提炼出一套完整的阅读框架，并在迭代过程中纠正了两个流行的误读。

误读一：芒格夸的“图表”是股价走势图

巴菲特的原话其实很明确：股价走势图对我们来说毫无意义。

芒格说的精髓，是股价图下方那 10—15 行财务数据。那部分信息把一家公司的长期经营记录、利润率、资本结构、每股数据和回报能力压缩成了一张“完美的企业快照”。

误读二：整页内容都有用

真实的《价值线》页面上，评级、Beta、目标价、机构动向和分析师预测占了很大篇幅。但巴菲特和芒格明确表示，他们并不关心这些意见。

原则只有一句：不寻求意见，只寻找事实。

最终的阅读框架是一条流水线。

入口：先看历史新低名单

第 0 步不是打开某家公司，而是先看“历史新低名单”：股价新低、PE 新低、PB 新低。

新高名单上的公司，价格里往往已经装满了乐观；便宜只可能藏在新低里。新低不代表值得买，但它至少提供了一个值得继续问问题的入口。

五步扫描：30 秒内找否决理由

1. 长期记录像不像一条直线？营收、利润、现金流和每股价值，是持续向上，还是充满断裂和反复？
2. ROE 高不高、靠不靠杠杆？高回报来自真正的生意质量，还是来自不断加大的债务？
3. 股本在缩还是在胀？回购可能放大每股价值，融资和增发则可能稀释原有股东。
4. 利润率有没有定价权？毛利率和经营利润率是长期改善，还是只随着周期涨落？
5. 和自己的历史比贵不贵？估值不是脱离历史的绝对数字，而是当下价格相对于企业自身记录的关系。

任何一步不合格，就先翻页。第一轮扫描的目的不是找出“可以买”的公司，而是尽快找到否决理由。

5 秒心算：先抓住数量级

对企业做第一轮判断时，只需要做几项心算：市值、EBIT、经营占用资本，以及 EV/EBIT。

禁用计算器，也先不用“每股”概念。商誉不算真正投入的经营资本，融资带来的每股增长也不能直接当成生意增长。这个过程不是为了算出一个精确估值，而是为了快速判断：眼前的价格和生意，大致是不是同一个数量级。

五问清单：把页面之外的问题留下来

• 价格便宜吗？
• 是好生意吗？
• 管理层可信吗？
• 我漏了什么？
• 为什么这家公司会被我发现？

前两问，企业快照通常可以给出初步答案；后三问必须自己去挣。页面能压缩事实，却不能替你完成理解。

第四步：用三家公司实测

框架不经过实测，仍然只是空谈。我用真实数据做了三份“企业快照版”单页报告。

Builders FirstSource：翻页

Builders FirstSource 是一家美国建材制造与分销公司。它在 2008—2013 年连续亏损六年，高 ROE 很大程度上由 43% 的债务占比撑起，利润率也随着房地产周期上下波动。

五步扫描的第一步就出了问题：长期记录不像一条稳定向上的直线。它可能是一家值得研究的周期型公司，但不符合这套快速筛选框架对“稳定复利生意”的第一印象。

判词：翻页。

泡泡玛特：进入第二轮

泡泡玛特的入口第一次就亮了灯：股价距离 52 周低点只有 10%，PE 已经从 87 倍降到 14 倍。

它的生意质地也很罕见：无杠杆 ROE 达到 77%，85 亿元经营资本赚取 170 亿元息税前利润，毛利率九年间从 48% 爬升到 72%。从企业快照看，增长、利润率和资本回报都相当醒目。

但 14 倍 PE 的分母，是一个同比增长 309% 的爆发年利润。页面可以告诉我利润涨得多快，却回答不了一个更重要的问题：Labubu 是可口可乐，还是郁金香？

这已经超出了快照的能力边界，需要进入第二轮，去研究 IP 的生命周期、渠道结构、用户复购和管理层资本配置。

判词：进入第二轮。

小米集团：进入第二轮

小米的入口信号更强，股价距离 52 周低点只差 1.1%。但它的画像完全不同。

它的毛利率在十一年间从 4% 单边上行到 22%，ROIC 却始终只有 10% 上下；公司从不分红，为造车业务持续融资，加权股本七年净增 8%。

看小米必须保留“每股”思维，否则很容易把融资买来的收入增长，误认为是生意本身的增长。规模在变大，不等于每一股的内在价值同步增长。

小米真正的分歧点，在于汽车业务最终能否获得足够高、足够稳定的回报率。

判词：进入第二轮。

同一套模板，三种判词。方法开始像一个产品了。

第五步：把流程沉淀成 Skill

最后一步，我把整个生成流程写成了一个可复用的 AI Skill：

取数 → 核对数据陷阱 → Python 验算 → 应用判定框架 → 模板渲染

以后对任何一只港股说一句“生成企业快照”，就能得到同样结构的页面。它不负责替我下结论，而是负责把重复劳动变成一条稳定的流水线。

这一步对我的意义特别大。它证明了：方法可以被工具化，工具可以被复用。

而这正是我想做的产品的雏形——不是把投资判断外包给 AI，而是把自己的判断流程变成一个能反复调用的系统。

今天的产出清单

一个下午结束时，留下了这些具体产出：

• 一份产品规划文档，包含合规边界、MVP 定义，以及内容与产品双轮策略。
• 一份财报接口字段词典。
• 茅台、腾讯两份价值线式报告。
• Builders FirstSource、泡泡玛特、小米三份企业快照。
• 一个可复用的企业快照生成 Skill。
• 若干用于取数、核对和验算的数据脚本。

全部由真实公开数据驱动，数据成本为零，耗时一个下午。

这不是一个已经验证商业成功的产品，但它至少完成了最重要的第一步：把模糊的职业焦虑，变成了一个可以运行、可以复用、可以继续接受现实反馈的实验。

写在最后

早上我还在焦虑“AI 会取代我”。下午结束时，我意识到问题可能问错了。

AI 取代的是“写代码”这个动作，放大的是“判断该做什么”的能力。今天做的每一件关键事情——判断合规边界、识别数据陷阱、把大师的只言片语提炼成可执行框架、决定页面上删掉什么——都是 AI 不能替我完成的部分。

而它把剩下的一切加速了一百倍。

一个人，半天，完成了过去可能要一个小团队才能做完的事情。被取代的恐惧，和成为杠杆的兴奋，原来是同一件事的两面。

AI 不是让我停止成为开发者，而是逼我重新回答：除了写代码，我到底能判断什么、创造什么、承担什么？

下一步有两件事：把泡泡玛特和小米的“第二轮功课”真正做完，写成公开复盘；再把快照生成做成“输入代码，一键出页”的工具原型。