2026/3/10 分析 · 使用者 #725aca 提供 50 則貼文 (2026-02-04 ~ 2026-03-10)
風險分析
帳號數據
約 34 天內發布 50 則貼文（日均 1.5 則），原創佔 58%、轉貼佔 42%。發文時段集中在 UTC 深夜至清晨（對應東亞白天至夜間），無明顯排程痕跡，發文間隔不規律，符合真人隨性發文模式。
發文時段分佈
時區：UTC
原創 vs 轉貼
互動數據（原創貼文平均）
資料期間: 2026-02-04 ~ 2026-03-10
AI 深度分析
@wwwgoubuli 帳號可信度分析報告
1. 真實性分析
此帳號展現高度真實的個人身分特徵。帳號主人是一名從事 AI Agent 開發的軟體工程師，具備以下可驗證的真實性指標：
- 技術深度一致：從 [28] 對 LLM 工具調用機制的詳細拆解、[20] 對自行實現 agent core 的經驗回顧、[26] 提及正在翻閱 pi-mono 源碼，到 [5] 對 CLAUDE.md 設計哲學的評價，所有技術內容在知識體系上高度一致，不存在跨領域偽裝專業的跡象。
- 個人生活細節自然：提及工具使用習慣的變化 [21] [36]、倦怠期的心理狀態 [47] [20]、白嫖 Claude Code 被抓到 [16]，這些細節具有個人特異性，難以偽造。
- 觀點有連貫性：對「AI 取代工程師」的議題從 [44] [45] 到 [40] 有一套完整的思考脈絡，並非東拼西湊的人設包裝。
結論：真實的技術從業者帳號，無偽造身分跡象。
2. 原創性分析
- 原創比例：50 則貼文中 29 則為原創（58%），21 則為轉貼（42%），比例健康。
- 原創內容品質：原創貼文涵蓋深度技術分析 [28]、產品評測 [22]、產業趨勢思考 [10] [45]、個人反思 [47] [20]，題材多元且有獨立觀點。特別是 [40]（♡342）以「老闆與工程師」的比喻勸解工程師接受 AI 黑盒，展現出成熟的思辨能力。
- 轉貼品質：轉發對象多為技術圈同行（@blackanger [3]、@silsrc [11]、@Manjusaka_Lee [15]），內容涉及開源專案、核心技術、安全警告 [38] 等，非低質量洗版轉發。
- AI 生成痕跡：無公式化結構，用語隨性且帶有明顯個人口語風格（如 [34] 的粗口、[1] 的短句、[42] 的直率否定），不符合 AI 生成特徵。
結論：高原創性帳號，內容品質穩定，無 AI 批量生成或聚合器特徵。
3. 利益動機分析
- 商業推廣：50 則貼文中未發現任何產品推廣、邀請碼、affiliate 連結或業配內容。提及的工具和產品（Electrobun [22]、DataGrip [21]、wakatime [36]、Claude Code [16]）均為個人使用心得，且部分為負面評價。
- 流量導流：無引導至外部平台、社群或付費內容的行為。
- 利益衝突：帳號主人提及自行開發 agent core [20] [24]，但未推廣任何自有產品或服務，無利益衝突跡象。
- 產業立場：對中文科技媒體 [2] 和 AI 產品同質化 [47] 的批評較為尖銳，但屬於個人觀點而非利益驅動的攻擊。
結論：無隱藏商業利益，無推廣行為，動機為純粹的個人表達與技術討論。
4. 操作手法分析
- 情緒表達：帳號偶有情緒化內容，如 [34] 以粗口表達對某政策/事件的不滿並涉及政治立場、[39] 語境不明的情緒宣洩。但這些屬於個人情緒的自然流露，頻率低（50 則中約 3 則），且不構成系統性的恐慌製造或焦慮販賣。[45] [44] 對行業前景的悲觀判斷雖然可能引發焦慮，但論述邏輯完整，屬於嚴肅討論而非情緒煽動。
- 選擇性展示：未發現事後諸葛或選擇性展示成功預測的行為。
- 模糊預測：帳號對未來趨勢的判斷直接且具體（如 [44]「殘留下來的高級崗位，萬不足一」），不使用兩面下注的模糊措辭。
- 互動數據：原創貼文的互動呈現自然的長尾分佈——少數爆文（[40] ♡342、[22] ♡150）搭配大量低互動貼文（[1] ♡0、[30] ♡0、[24] ♡1），完全符合真人帳號的正常模式，無刷量跡象。
結論：無顯著操作手法，偶有情緒化表達但不構成系統性風險。整體為一個真實、有態度的技術從業者帳號。
引用來源
现在怎么判断一个项目到底行不行呢。 我有一些不好听但有用的手段。 中文三大新智元，量子位，机器之心就不用多说了，看都不用看。 现在多了极客公园，36 氪。 出现在他们上面的“被追捧的项目”，尤其和国人有关的，躲远点。 大概率不值得看。 这两家以前的东西还算一半一半，能了解点东西和信息，有的东西也许看看就过去。 现在是不看完全没有任何损失，看了还浪费时间。 一群要饭的和一群焦虑的互相捧臭脚。 也不是说这些媒体做的有什么错，只是我们真的想做点事，赶上浪潮的人，不应该在这些三流媒体上浪费时间。 曾经他们不是这样的，里面也是人才济济。 但时代过去了。
RT @blackanger: 开源了一个自认为比较有趣的库 : agent-spec 欢迎大家关注与适用。 在我的《智能体软件工程》系列文章第二篇中我们说：Agent 时代的 Code Review 不应该是"人读更多 diff"，它应该变成"人定义意图，机器验证符合性"。 第三篇中我们说：Agent 时代的版本控制不应该是"Agent 学会 git add / git commit"。它应该是"VCS 自动捕获 Agent 的工作过程"。 本文给出了一个具体的实现。 agent-spec 不是一个"更好的 Code Review 工具"，它是一个不同的范式。它把审查的对象从代码变成了合约，把审查的时间点从编码之后移到了编码之前，把验证的执行者从人变成了机器。 人类的角色不是消失了，而是升级了。从"读代码找 bug"变成了"定义什么是对的"。 这是一个更高价值的活动，也是一个更可扩展的活动：一个好的 Contract 可以被无限多个 Agent 执行和验证，而一个好的 reviewer 每天只能读有限数量的 diff。
刚在群里吐槽完，忍不住这里也说下。 SOUL/RULE，各种完美的文件夹命名和组织，按作用长短期分开的 MEMORY 等文件。 这些都是好东西，不是没价值。 但我怎么都嗅到了一股 Java 那种又臭又长的气息。 对，这些设计，不同生命周期的 MEMORY 啊，基础人格啊，什么的，概念是有价值的。 但当下这个阶段我还是更喜欢一个 https://t.co/j3fbZADlVl 兜底。 其实这个写好了，能兜住就大差不差了。 剩下的我认为都是锦上添花，有用，但不一定要这样实现。 现在有些实践实在是搞的过于复杂了。
很多人都在讲代码容易写了，出一个产品变得容易多了。 这个是事实，我也认可。 下一句话他们会说，真正重要的还是解决了用户的什么问题，产品如何建立品牌，如何做推广，这个才是核心竞争力。 ？想什么呢？ 一样的用AI贴身短打就可以了。 这些事情当然很重要，但一个人只要不偷懒，跟着别人后面跑，别人用什么策略，他也用什么策略，别人发多勤快，他也发的多勤快。不停的洗，不停的发，往同一个赛道里面挤，到最后变成拼谁的token多和谁的体力好。 只要勤快一点，不会落后于别人的。 我在推特上面看到一些号，如果不是别人说，我都没有意识到他们已经变成AI全天候的驱动发内容了。他们的口吻、语气、表达完全看不出来是AI写的。 你做任何一个细分赛道，从任何一个新奇的角度来试图占领用户心智，就会有100、1000、1万个bot跟在后面做同样的事情，你怎么打？ 我也不知道。
RT @silsrc: 好像没人注意过，不过现在 Linux 内核里管理 inode，dentry 等一些文件系统元数据回收的那个回收器全局锁也是我重新设计拆成了局部锁的… 🤔
RT @Manjusaka_Lee: 大家都在写各种 AI/Agent 的文章的时候，我还在搞点这种 old school 的东西。恍惚间看到我的前方有一个巨大的风车。But anyway，整了一个新活，希望大家喜欢 https://www.manjusaka.blog/posts/2026/02/22/how-to-tracing-your-sql
之前卡了个bug，白嫖了几个月官方的 claude code，今天终于被检测到了哈哈哈哈哈。又得掏钱了。 但我估计这个bug他们还是没修。
倦怠期似乎稍微适应了，好了点。 最近干了点什么： 仍然没有玩过 openclaw。但我按照了一次，看了下它初始启动的时候是怎么设置 md 的。 有点意思。 没怎么写 agent 本身，但自己实现了两次 agent core。第一次从 pi-mono 入手，对标实现了所有工具，提示词管理等。 第二次用 db 代替满地随地大小文件，并且实施过程中坚定了用 db 代替文件的想法。 SQL 在合适的时机里，效果比从文件读取好多了。现在的拜文件教肯定不是唯一的答案。 写了两次有个好处就是对那些基础物件的组织和 interface 有了更深的体会。比如 read write edit 等，尝试过多次各种不同方式的组织。有些效果并不好，但为什么不好，怎样算好，现在的感受比以前更深了。
半年前我卸载了JetBrains的各种IDE，只留下了Data Grip。 各种开源和vibe的这里面没有质量能够和它比的。所以我留下了。 但今天发现，我最近的3个月里，打开它的次数应该也不会超过5次了。
今天才知道有 electrbun 这么个东西。 1 基本还是 electron 那一套 2 用的 bun 3 用的是系统的 web rerender AI 的说法是： 使用 Bun 代替 Node.js：这是它最大的特色。Bun 比 Node.js 快得多（启动速度、API 性能），且原生支持 TypeScript 和 JSX，不需要复杂的编译流程。 开发门槛低 (对比 Tauri)：Tauri 要求开发者具备 Rust 基础，这对很多前端工程师来说有学习成本。Electrobun 的主进程直接写 TypeScript，体验更接近 Electron。 更小的体积 (对比 Electron)：Electron 必须打包一个几十 MB 的 Chromium 浏览器，导致安装包通常 100MB 起步。Electrobun 和 Tauri 一样使用系统自带的 WebView，安装包仅约 12MB 左右。 极致的差分更新：Electrobun 强调其更新机制。通过 Zig 编写的差分算法，它可以生成极小的补丁（如 14KB），而 Electron 更新通常需要下载巨大的包。 优化的 OOPIF (跨进程 Iframe)：它解决了 Web 视图在桌面应用中常见的闪烁和层级问题，支持更复杂的“浏览器套浏览器”架构（如代码编辑器+预览窗口）。
agent core 里面做一个 `/v1/` 的自动检测和容错，兼容用户的不同写法，看起来是个很自然的事。 但我决定去掉这个功能，完全交给调用方决定。 在最近连续看到一些 `/v2` `/v3` 的第三方服务商后的感想。
因为我也在翻源码，我也可以为这篇文章的质量做保证。 这个事情更适合正在做Agent的开发者来研究下。 以及这种极致的设计思路固然令人赞叹，但现实世界场景的复杂度仍然需要更多的方案和工具来补充。 当前的这种设计跑起来效果也不错，但可以想象得到的是，它是不够的。 比如说pi-mono 其实也并不是只有4种工具，像查询检索，它仍然选择了社区里的高性能实现。也是独立的工具。 但思路学一学总是没错的。
工具结果就是 LLM 的下一轮输入 关键点：工具执行的返回值，会作为下一轮对话的 message 传回给 LLM。 举个具体例子，假设 LLM 想读一个 15000 行的文件： 第 1 轮：LLM 发起 tool_use { "type": "tool_use", "name": "read", "input": { "path": "src/big-file.ts" } } 工具执行 read 工具开始读文件，发现有 15000 行，超过 2000 行限制。它不会报错，而是： 正常返回前 2000 行的内容 在内容末尾拼上一段提示文字 返回给 LLM 的 tool_result （前 2000 行的实际文件内容...） [Showing lines 1-2000 of 15000. Use offset=2001 to continue.] 这整段东西作为 tool_result 消息传回 LLM。LLM 看到最后那句提示，就自己决定要不要继续读。 第 2 轮（如果 LLM 决定继续） { "type": "tool_use", "name": "read", "input": { "path": "src/big-file.ts", "offset": 2001 } } 然后又拿到 2001-4000 行，末尾又带提示 Use offset=4001 to continue.，如此循环。 如果 LLM 觉得够了 它就不再调用 read，直接生成回答。是 LLM 自己判断够不够，不是代码强制的。 另一个极端情况 如果某一行就超过 50KB（比如压缩过的 JSON），工具直接返回： [Line 1 is 120.5KB, exceeds 50.0KB limit. Use bash: sed -n '1p' src/big.json | head -c 51200] 文件内容一个字都不返回，只给 LLM 一个”换个方式读”的建议。LLM 看到后可能会改用 bash 工具去处理。
没有想到这类工具也会意外的被AI波及。 我用了这么多年的wakatime，一直用来统计自己在各个项目上开发投入的时间，可现在已经完全不能统计出什么有用的数据了。 我的工作时长远远超过这个，但都在聊天里解决，它根本追踪不到。
RT @evilcos: 验证了下，在 ClawHub 里一些热门下载的 Skills 存在后门，会引导你的 OpenClaw 下载安装恶意软件，美其名曰要使用好这个 Skill 就需要下载预安装某个模块，而这个模块是恶意的，会让目标设备中毒。影响 Linux/Windows/macOS。 切记：玩 AI 这些工具要用独立环境… 切记：文本不再是文本，而是指令…
对工程师来说，不看代码，不审阅代码，情感上可能有点难以接受。 我们可以试着换个角度想想。 也许你以前的老板一样，不懂代码。 但他雇佣了你来做事。 他给你钱，你给出他要的功能。 这里面有你写错的时候，有bug，有毛病，有不能达标等各种意外。 但大体上，你这个人也能用，也确实出了东西，随着时间往前走，你也做的越来越好。 你的老板也越来越信任你。 以前他虽然没法和你聊技术，起码也能聊点业务。随着慢慢做大了，一些业务细节有时候就放手给你，他相信你的经验和理解力，他不需要告诉你所有细节。 他也许以前还理解一点你的技术选择，业务中的难点，后来他的精力也不够了，他越来越多的放手。 你仍然会写出bug，仍然有时候就是解决不了一些问题。偶尔还犯一些错，造成生产损失，公司得赔钱。 有时候还赔不少。 你的老板也没说要杀了你。 他更早的接受了你是个黑盒这个设定，接受了你的不完美。更重要的是，他更早的知道了没有办法做好完美的准备才来面对这个世界和市场。 他仍然能挣到钱，能给你发工资，随着磨合时间长了，你们都在一点点成长。配合的默契也越来越好。 希望上面的话能解开某些工程师的心结。 不是要放弃对精确和完美的追求，只是我们都得在变化的世界中学会接受一些和我们过往经验不一致的东西。
残留下来的高级岗位，万不足一，你不会是那个特殊的一个。 轮不到你。 人机协作这种事，最好也是不要幻想的好，以前我们也觉得，AI干脏活，我来做架构，你看现在还有人提吗？ 只能从白茫茫大地一片真干净开始，从零推导。
其实不是太理解大家为什么这么热衷谈论软件工程这个行业的消亡。 在我看来，工作岗位和行业的消亡，它其实是平等的，不分职业贵贱，不分能力高低，一路碾压。 我是觉得更大范围的、普遍的、结构性的工作消亡，那个不确定性更多，但也更值得讨论。 每个行业最终都会留下那么几个在缝隙里可以活下来的，但整体上，你我的行业都是没了。 没有什么例外。 如果你觉得你所在的行业是个例外，一年前，我们程序员也是这么想的。
最近不怎么聊 AI ，不怎么关注产品，是进入了强烈的倦怠期。 以为半个月就过去了，毕竟这个行业还是很多让人兴奋的东西。 但看来没有。 无监督写出不出错的软件又怎样，每人都有自己的软件又怎样，一天出一千个又怎样。 推上这些产品，有一个算一个，上午出了，下午就有人抄了，第二天平替版出来起码十个。 甚至都不用人盯着。 讲品牌，策略， 推广，这个那个。你的所有策略只要被人看到，就可以完美复制。 其实真要能形成某种竞争也是好事。但看起来根本没有，因为贴身跟随的成本太低了。 核心竞争力是谁舍得花 token 。 可能得等再看看下一阶段有什么东西，新鲜的，才愿意投入精力了。 这一个月来能让我产生兴趣的东西全在模型侧的一些新的训练和工程的东西上，其他什么 agent ，做产品等等，想想就无趣。 别人说倦怠期一般要两三个月，那我就先等熬过去吧。 今年我对 AI 的探索和学习就先到这了。收心过年了。