“写笔记”支持四种格式——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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
循环工程详解：面向开发者的实战指南
说实话，第一次听到“循环工程”（Loop Engineering）这个词的时候，我第一反应是：“又来一个营销新词？” 但后来我仔细想了想，发现这玩意儿其实挺实在的，不是什么玄学。
简单点说，循环工程要做的事情就是：把我从“不断给AI助手写提示词”这个苦差事里解放出来。
以前是我发现一个问题，分析一下，然后写个prompt，等AI回答，不满意再改，再问……整个流程我就是那个“人肉循环”。现在不一样了，我设计一个系统，这个系统自己会转，直到达到我想要的结果。我不再是操作员，我是系统设计师。
为了把这事儿讲明白，我拿一个真实的软件工程场景来做例子：CI（持续集成）失败自动处理。当GitHub Actions的CI跑挂了，系统会自动分类失败原因、创建Jira Bug、发Slack通知，并且记录状态，避免重复处理同一个失败。
循环工程到底在说什么？
早期的AI工作流，大部分是线性的。你给我一个prompt，模型给你一个答案。如果答案不对或者不完整，你跳回来，再写一个prompt。这是最原始的人肉迭代。
这种模式的问题在于：你被困在流程里了。你就是那个“胶水”，把每一步粘在一起。
循环工程改变了这个关系。你不再是每个步骤的“保姆”。你构建的是一个能自主运行的循环系统，它能观察、决策、执行、并持久化状态。系统自己迭代，直到任务完成，不需要你在旁边盯着。
这个区别很重要：
- 传统prompt工作流：人是胶水
- 循环工程：人创造机器，机器跑循环
循环工程的五个核心构件
我把循环工程拆成了五个部分，它们一起工作，缺一不可。
1. 自动化触发器（Automations）
这是整个系统的“心跳”。没有这个，什么都没有。它是事件驱动的，比如：CI失败、GitHub push、定时任务……只要条件满足，它就启动整个流程。
2. 技能（Skills）
技能给AI Agent提供了结构化的上下文。你不需要让AI每次从头“猜”你们团队的惯例。你把团队约定、项目规范、处理流程这些上下文一次性编码进去，Agent就能带着这些“背景知识”去工作，每次都是一致的。
比如，你可以定义一个“CI失败分类技能”，告诉Agent：“如果日志里出现timeout，可能是环境问题；如果出现assertion error，可能是代码bug；如果测试反复无常，可能是flaky test。” 这些知识只写一次，系统每次都用。
3. 子代理（Sub-agents）
这里开始变得有意思了。一个Agent负责生成输出，另一个Agent负责验证或分类。生成和验证其实不是同一个技能，分开来更靠谱。
举个例子：第一个Agent分析CI日志，输出“这是一个bug”。第二个Agent专门检查这个分类是否合理，看看置信度够不够，有没有遗漏关键信息。如果两个Agent意见不一致，系统可以走人工审核或者重新分类。
4. 连接器（Connectors）
循环工程不能只活在AI的“脑子里”。它必须能对外部世界产生影响。连接器就是干这个的。Jira、Slack、GitHub、PagerDuty……系统做出一个决策，就要通过连接器去执行。
比如：分类结果是“bug”，那就通过Jira连接器创建一个issue；同时通过Slack连接器发一条通知。这些连接器是系统的“手脚”。
5. 状态文件（State Files）
状态就是记忆。循环系统必须能记住它已经处理过什么。不然同一个CI失败，每次触发都重复处理一遍，系统就会变得又吵又不可靠。
状态文件可以是一份简单的JSON，记录每个CI run的ID和处理结果。下次同一个run ID进来，系统直接跳过。这是避免重复处理的关键。
为什么选CI失败这个场景？
我想找一个真实的、团队每天都在遇到的问题，而不是一个玩具Demo。CI失败就是完美的例子。
想想看，一个CI跑挂了之后，通常会发生什么：
- 有人发现失败了
- 有人检查是flaky test、环境问题还是真bug
- 有人创建一个Jira issue
- 有人在Slack里发消息
- 有人追踪这个问题是不是已经处理过了
全是手动操作，全是重复劳动。
Google SRE 对“Toil”的定义很到位：Toil 是随着团队规模线性增长的重复性手动工作。团队越大，CI失败越多。如果处理这些失败还是靠人每天重复同样的步骤，成本会爆炸。
所以我的目标很简单：用循环工程把这些Toil尽可能消除掉。
我构建的循环系统
整个循环是这样的：
- GitHub Actions的CI跑失败了
- 自动化触发器被激活
- AI对失败进行分类
- 如果是flaky test，系统记录下来，跳过Jira
- 如果是真正的bug，系统自动创建Jira ticket
- 系统发送Slack通知，包含详细内容
- 结果写入状态文件，保证同一个失败不会被处理两次
这就是一个非常实际的循环工程例子。中间没有任何手动prompt，不需要等人发现失败，没有反复的手动交接。
实际工作流长什么样
我用 Port.io 构建了这个工作流。它本质上是一个七节点的流程，专门处理CI失败。
流程大概是：
- 工作流状态变更 -> 触发
- 分类CI失败
- 根据分类结果分支
- 如果是flaky test -> 记录日志，跳过Jira
- 如果是bug -> 创建Jira bug，发Slack通知，更新Port中的run状态
这里的关键是：循环系统不只是“做决策”，它还在多个工具之间执行动作，并且把结果写回系统。这就是循环工程超越理论的地方。
一次真实的测试
为了验证这个系统，我故意搞了一个CI失败：在一个GitHub仓库里直接修改README文件并提交到main分支。这个修改触发了CI工作流，我让这个工作流故意模拟一个失败。
然后，整个链条自动反应了：
在Port里，一个新的工作流run出现了。系统自动捕获了失败，分类，然后继续走自动化路径。
接着，Jira里自动创建了一个bug。这个issue包含了很详细的信息：
- AI分类结果
- 置信度
- CI失败摘要
- 工作流名称
- 分支
- 提交信息
- 执行者
- Run URL
- Port实体引用
同时，Slack里也收到了一条通知，包含同样的核心信息，以及指向GitHub、Jira和Port的链接。
这就是循环工程真正“click”的时刻：失败发生了，系统自己推理、自己行动、自己记录结果，全程不需要我插手。
为什么这事儿比你想象的更重要
很多人听到“自动化工作流”就觉得只是“方便一点”。我觉得不止。
想象一个CI失败发生在凌晨3点。正常情况下，得有人第二天早上发现它，检查它，然后决定怎么办。这个延迟会拖慢团队，尤其是当失败堆积起来的时候。
但用循环工程的方式，第一次响应是立刻发生的。即使循环系统现在还不能自动修复问题，它已经消除了所有无聊的操作开销：
- 检测是自动的
- 分类是自动的
- 路由是自动的
- 通知是自动的
- 状态跟踪是自动的
这已经是巨大的进步。等循环系统成熟了，它还可以从“报告”扩展到“修复”。
构建这个系统需要什么
说实话，前置条件很简单：
- 一个 Port.io 账号
- 一个 GitHub 账号和仓库
- 一个 CI 工作流（GitHub Actions）
- 一个能把CI run元数据上报给Port的工作流
- 一个 Jira 项目和凭证
- 一个 Slack 应用和 Bot Token
两个关键的GitHub工作流文件
我在仓库里用了两个YAML文件。
第一个是主CI管道。它模拟了一个测试失败，在我做Demo那种修改时触发。
第二个是一个Port CI上报工作流。它的任务是在CI run完成后，把run的元数据上报给Port，进行一次upsert。这个元数据包括：工作流名称、分支、提交信息、执行者、run URL。
第二个文件很关键，因为它是连接GitHub和循环工程系统的桥梁。
Port内部各组件如何连接
在Port里，我把自动化、技能、子代理、连接器和状态文件配置好，然后整个流程就串起来了。
具体来说：
- 自动化监听GitHub的workflow_run事件
- 触发后，调用AI分类技能
- 分类结果决定下一步走哪个分支
- 连接器负责执行Jira创建和Slack发送
- 状态文件记录处理结果
整个配置过程不复杂，但需要你理解每个构件的作用，以及它们之间怎么配合。
最后说几句
循环工程不是什么高深莫测的东西。它本质上就是把你从一个prompt的奴隶，变成系统的主宰。你不再需要盯着每一个步骤，而是设计一个能自己跑的循环。
对于CI失败这种高频、重复、低价值的任务，循环工程的效果立竿见影。而且一旦你掌握了这五个构件，你可以把它扩展到很多其他场景：代码审查、部署监控、告警处理、甚至自动修复。
希望这篇文章能帮你真正理解循环工程是怎么回事，而不是只会说这个词。如果你也试了，欢迎来聊聊你的经验。