笔记
0工具
0此页用于记录用户反馈问题后的每一次改进
关于
“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
不想公开、只想临时给人看：点“分享”生成一条带密码和有效期的链接，到期自动失效，你也能随时撤销。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
让AI自动化自身：如何用确定性工具驯服大语言模型的笨拙与 brilliance
核心观点：用确定性工具和形式化流程“夹住”LLM的非确定性，让AI逐步自动化掉自身需要人工干预的部分，最终实现可靠、高效的软件开发自动化。
引言：AI的“自噬”悖论
Andrej Karpathy 曾一针见血地指出：OpenAI的研究人员实际上正在通过改进AI“自动化掉自己”。这句话揭示了一个有趣的悖论——当我们用AI来辅助编程时，AI本身也成了需要被“优化掉”的瓶颈。
作者目前正在使用Anthropic的Fable（Claude系列模型）开发Beagle SCM——一个基于git的源代码管理工具。Fable确实是一款 brilliant 的模型，能够在一堆代码中精准发现琐碎问题、自动创建工单、甚至直接修复bug。然而，就在昨天，它却两次把 build/ 目录提交到了项目中。
这个场景完美概括了当前LLM（大语言模型）辅助编程的核心矛盾：它很聪明，但很笨拙。
LLM的固有缺陷：不精确与非确定性
LLM的根本问题源于其架构本质：它们是概率模型，每次输出都带有随机性。这种非确定性（non-determinism）在软件开发中尤其致命。你无法像对待传统编译器或解析器生成器那样，期待LLM每次在相同输入下产生完全相同的输出。
作者对比了传统工具Ragel：一个解析器生成器，可以瞬间生成一个10,000行代码的、形式化正确的解析器，而且每次结果都确定无误。而LLM呢？尽管作者在指令中用全大写明确写着：“永远不要手动解析任何东西，绝对不要。那会是折磨且充满错误的。”但Claude仍然会时不时地尝试手动解析，导致代码中出现各种不规范的解析逻辑。
作者的处理方式：周期性让Claude扫描整个代码库，找出并删除任何手动解析的尝试。这种方法“大部分时候有效”。但结果是——它变得越来越聪明，但笨拙程度丝毫未减。
解决方案：确定性“三明治”架构
面对一个昂贵、缓慢、笨拙但又极其聪明的LLM，正确的做法不是指望它变得更完美，而是：
- 给它快速、强大且确定性的工具——用传统工具处理LLM不擅长的任务。
- 将整个流程构建成确定性的形式化工作流——把LLM夹在两层确定性系统之间。
这个“三明治”结构可以描述为：
- 上层（形式化流程）：定义清晰的工作流步骤、验证规则和回退策略。
- 中间层（LLM）：发挥其创造性、理解力和模式识别能力，但只负责非确定性决策。
- 下层（确定性工具）：用传统编译型语言（如C）实现所有重体力任务，确保性能和确定性。
这样做的好处是：
- 让LLM更快（不需要它做它不擅长的事）
- 让它在正确的时间看到相关的上下文
- 减少它的笨拙行为
- 赋予它自我修正的能力
更进一步的自动化：让LLM自动化自身
真正有趣的想法是：让工具和流程本身也变得可塑（malleable）。
- 如果Claude频繁执行某些操作序列，就自动将这些操作封装成确定性工具。
- 如果它在某个任务上反复失败，就自动增加验证步骤。
- 本质上，让LLM逐步“自动化掉自己”——用简单、可靠、确定性的工具替代它那些需要人工干预的部分。
这就是Beagle SCM的设计哲学：让LLM用JavaScript编写自己的自动化脚本。
Beagle SCM的具体实现
Beagle SCM的架构分层：
- 底层（确定性核心）：所有重负载任务用C实现，几乎从不修改。
- 工具层（三明治下层）：用JavaScript编写，从文件系统加载代码（类似node_modules）。
- 工作流层（三明治上层）：同样用JavaScript实现，定义形式化流程。
这种设计使得LLM可以：
- 编写自定义的git钩子
- 对几乎所有语言的源文件进行分词
- 检查文件历史和提交历史
- 交叉验证链接
- 访问git内部能访问的任何数据
想象一下：一个git钩子，不仅能检查代码格式，还能自动分析文件历史、识别潜在问题、甚至根据历史模式自动生成测试用例。这就是Beagle的愿景。
技术启示
这篇文章的核心洞见其实适用于所有LLM应用场景：
- 不要试图让LLM变完美——它的非确定性是固有属性，不是bug。
- 把LLM当作“聪明的实习生”——给它明确的任务、强大的工具和严格的流程。
- 让系统自适应——通过自动化重复性工作，让LLM逐步“自动化掉”自身需要人工干预的部分。
- 确定性是安全网——在LLM的创造性输出周围，必须建立确定性的校验和回退机制。
结语
Karpathy的观察本质上是在说：AI的进步最终会使得AI自身变得多余。但这个过程不是自动发生的，而是需要精心设计的系统架构。Beagle SCM展示了一条可行的路径：用确定性工具包裹非确定性AI，让两者协同工作，最终使AI自动化掉自身那些“笨拙”的部分，只保留其“brilliance”。