AI 研发里的 memory，至少有三层
最近我在往外讲 hengshi-jarvis，经常会被追问：Claude Code、Hermes 这些工具也在讲 memory，mem0 这一类产品更是直接做 memory，JARVIS 为什么还要反复讲 memory。原因不复杂，这里本来就混着三层东西：coding agent 自带的 memory、mem0 这一层把资料单独存和找回的 memory、还有 jarvis-types 这种会直接改执行顺序的组织…
2015—2026
Memories
从较新的文章开始，慢慢往下读。
22 篇文章
2015—2026
主文
2026.05.14
继续阅读
从较新的文章开始，慢慢往下读。
Harness 之后，公司还是得有自己的 JARVIS
接着上一篇往下写。上一篇讲的是 JARVIS 最近一个月收进了哪些运行规则。这篇换个角度，把 OpenAI、Martin Fowler、LangChain、Mitchell Hashimoto、Tanka、ArcKit，还有最近几篇中文文章放在一起看。沿着这条线往下走，会更容易看清另一件事：agent 能跑起来很重要，但真进公司以后，最后还是得按这家公…
JARVIS 正在变成 AI 研发组织的运行中枢
这一个月我把 JARVIS 又往前推了一步。现在它会直接管 agent 从哪进来、在哪干活、先读什么、做到什么才算收口。说它只是知识库，已经不准确了。
JARVIS 与 Harness Engineering：AI 研发的记忆层和运行层
Harness Engineering 正在成为 AI agent 工程化的核心范式。但"让 agent 跑得稳"和"让 agent 知道该干什么"，是两个不同的问题。
AI 研发实验该怎么做：验证的不是代码产量，而是闭环能力
真正有价值的 AI 研发实验，不是看 AI 写了多少代码，而是看需求、实现、测试、验收、知识沉淀能不能形成稳定闭环
从 AI 写代码，到 AI 驱动研发：中间差了一个 JARVIS
让 AI 参与研发，难点从来不只是代码生成，而是如何让记忆、状态、工具和测试形成一个能长期运转的系统
为什么一次封闭式 AI 开发实验，测不出真正的上限
真正值得验证的，不是 AI 一次能写多少代码，而是它能否在需求、实现、测试、验收之间形成稳定闭环
构建软件公司的 JARVIS：AI Native 研发中枢的方法论
如何让 AI 从"工具"变成"研发团队成员"——一个经过验证的方法论框架
10 年工作回忆录
我的 10 年工作回忆录：从高中辍学生到资深工程师的蜕变之路
如何写好一个交互组件
什么是工程师思维
项目管理的一些思考
思考如何进行更好的项目管理
Javascript list cards fadeOut effect
js实现卡片列表上滑渐隐动效
d3.js 与 react.js
入门可视化图形
1000+ 项目中出现最多的 10 个 JavaScript 错误（及如何避免）
总结错误，提高自己
Null vs Undefined
Null 与 undefined 的相同点与不同点
JavaScript 框架们的残酷“框”生
聊一聊死在“沙滩”上的框架们
关于一些我不知道的 js 的东西
学无止境啊...
6 个原因告诉你 Async/Await 比 Promise 好用（教程）
抛弃 Promise 拥抱 Async/Await
前端 GraphQL 入门
了解一下什么是 GraphQL
用canvas写一个“火箭车”小游戏
闲的时候总想干点什么...