[{"content":"在构建复杂系统——尤其是现在的 AI Agent 架构或基础设施时，我越来越倾向于一个原则：白盒施工，黑盒交付。\n很多人把这两个词对立起来，但在我看来，它们是同一个产品生命周期中两个阶段的必然选择。\n1. 施工阶段：极致的透明（The White-Box Construction） 在开发阶段，任何形式的\u0026quot;黑盒\u0026quot;都是潜在的债务。\n所谓的\u0026quot;白盒施工\u0026quot;，是指在内部实现时，追求绝对的可见性和可追溯性。每一条 Prompt 的流转、每一个 Tool 的调用链路、每一个状态的变更，都应该是透明的。\n为什么必须是白盒？\n调试的成本： 当系统出现非预期行为时，如果内部是黑盒，我们只能通过猜测和试错来修复。而白盒施工允许我们像手术一样，精准地定位到具体哪个环节出了问题。 重构的勇气： 只有当你完全理解内部每一个零件是如何咬合时，你才敢在不破坏整体的情况下进行大规模重构。 在施工期，我们应该欢迎冗余的日志、详细的 Trace 链路和直观的状态面板。因为在这个阶段，透明度就是生产力。\n2. 交付阶段：绝对的简洁（The Black-Box Delivery） 然而，当产品面对用户时，逻辑必须瞬间反转。\n一个成功的交付物，应该是用户感知不到其内部复杂性的\u0026quot;黑盒\u0026quot;。用户不需要知道你的 RAG 链路是怎么检索的，不需要知道你用了多少个 Agent 进行了反思和博弈，他们甚至不应该意识到这些东西的存在。\n交付黑盒的本质是降低用户的认知负载。\n心智模型： 用户只需要一个简单的输入和确定的输出。一旦用户开始思考\u0026quot;系统内部是如何运作的\u0026quot;，就意味着产品的易用性出现了裂缝。 定义边界： 黑盒交付通过明确的接口（API/UI）定义了责任边界。用户关注结果，而我们负责确保结果的确定性。 3. 封装的艺术：从白到黑的跨越 最难的不是\u0026quot;白盒施工\u0026quot;，也不是\u0026quot;黑盒交付\u0026quot;，而是在两者之间建立一套完美的封装机制。\n很多团队在交付时，不自觉地把内部的复杂性泄露给了用户（比如让用户去配置复杂的参数，或者在界面上显示过多的技术细节）。这其实是一种工程上的懒惰——因为通过精巧的封装将\u0026quot;白盒\u0026quot;转化为\u0026quot;黑盒\u0026quot;，需要极高的抽象能力。\n真正的专业，是把所有精密且混乱的零件，封在一个光滑、简洁且坚固的壳子里。\n结语 白盒是为了掌控，黑盒是为了交付。\n我们在内部追求极致的透明，是为了在外部交付极致的简单。这种反差，正是工程美学的核心所在。\n","permalink":"https://famzheng.com/posts/whitebox-blackbox/","summary":"在内部追求极致的透明，是为了在外部交付极致的简单。白盒与黑盒不是对立，而是同一个产品生命周期中两个阶段的必然选择。","title":"白盒施工，黑盒交付：关于复杂系统的工程哲学"},{"content":"一个画家拿树枝在沙地上画，也能画出传神的线条——天赋和技巧不会因为工具简陋而消失。但要真正完成一幅作品，他需要安静的画室、趁手的画笔、合适的颜料和画布。少了这些，要么事倍功半，要么作品根本没法完成。\n我们不会说\u0026quot;这画家不行\u0026quot;。问题不在他的能力，在他的条件。\n但换一个场景：一个 AI Agent 反复调用工具失败、陷入死循环、输出一塌糊涂——我们的第一反应几乎总是\u0026quot;这模型不够聪明\u0026quot;。\n这个归因方向，往往是错的。\n一个公式 解决问题的能力 = 智力 × (环境 + 工具)\n智力决定上限。 理解意图、分解任务、做架构决策、在模糊需求中找到方向——这些是不可替代的核心能力。更强的模型能处理更复杂的问题，这是环境和工具无论多完善都给不了的。智力就是天花板，没有捷径。\n环境与工具决定下限。 文件系统、网络、依赖、权限是环境；API、CLI、SDK 是工具。它们决定了模型实际能发挥出多少水平。工具烂、环境差，再聪明的模型也被拖到地板上。\n乘法关系意味着：任何一侧趋近于零，输出就是零。画家的天赋再高，没有画布也只能在沙地上比划。\n智力决定你能走多远，环境和工具决定你能不能迈出第一步。\n实践 把地板垫高，核心就两件事：\n工具要给有用的反馈。 file not found: /path/to/config.yaml 比 operation failed 有用一百倍。前者指向下一步行动，后者触发盲目重试。模型没法搜 Stack Overflow，它只能分析错误信息本身——信息不够，就只能猜，猜就是死循环的起点。\n环境要有确定性。 同样的操作在相同条件下有时成功有时失败，模型就无法从结果中学到有效信息。固定依赖版本、确保配置一致、显式检查隐式依赖——这些基础工程实践在 Agent 场景下价值被大大放大。\n目标不是取代模型的推理能力，而是不浪费它。让智力花在架构决策和复杂问题上，而不是跟坏掉的工具搏斗。\n总结 模型决定上限，环境与工具决定下限。\n选模型是选天花板，不可替代。但别忘了脚下的地板——很多时候 Agent 表现不佳，不是不够聪明，而是烂工具把它拖到了远低于实际水平的位置。\n先修路，再选车。\n","permalink":"https://famzheng.com/posts/intelligence-environment-and-tools/","summary":"模型决定上限，环境与工具决定下限。","title":"智力，环境与工具"},{"content":"The dominant theme in software engineering for the past two decades has been continuous. CI transformed integration, CD transformed delivery — each wave of \u0026ldquo;continuousification\u0026rdquo; turned a discrete, human-dependent step into an automated flow.\nBut one step has remained untouched: generation.\nCode is written by hand. Documentation is written by hand. Test reports are assembled by hand. Config files are filled in line by line with the docs open in a split screen. Every engineering artifact is, fundamentally, handcrafted. The arrival of AI agents lets us ask for the first time: if all these artifacts can be generated from intent, should \u0026ldquo;handcrafted\u0026rdquo; still be the default?\nIda (Intent-Driven Agent) is a methodology built around that question. Its scope is engineering output with clear technical specifications that can be objectively verified — code, documentation, tests, configuration, reports. Organizational dynamics and process politics are out of scope.\nFive Core Principles 1. Intent is the source; artifacts are derived Humans provide goals and constraints. All engineering artifacts — code, docs, tests, reports, images, configs — are projections of those goals, not independently maintained first-class citizens. When upstream intent changes, downstream artifacts are regenerated.\nThis means our understanding of \u0026ldquo;source code\u0026rdquo; needs to shift up one layer: the true \u0026ldquo;source\u0026rdquo; is no longer the code file — it\u0026rsquo;s the intent in the human\u0026rsquo;s mind. Code is just one compilation target of that intent.\n2. Goals must be well-formed Not every sentence qualifies as input for Ida. A well-formed goal must satisfy four properties:\nComprehensible — the agent can decompose it into concrete actions Achievable — it can be completed within current capabilities Verifiable — completion can be objectively judged as correct or incorrect Decomposable — it can be broken into small steps with visible progress at each stage Refining a vague requirement into a well-formed goal is the human\u0026rsquo;s first job. This doesn\u0026rsquo;t lower the bar — quite the opposite. It demands that humans think more clearly and express themselves more precisely.\n3. Generation is an ongoing conversation The generation process is not a rocket you can only watch after launch. Humans can correct goals, add constraints, and give feedback on intermediate artifacts at any stage. Agents should proactively surface state and request confirmation at key checkpoints.\nIntent itself is iterative. Good intent often takes shape gradually through multiple rounds of human-agent interaction.\n4. Humans and agents each own their domain Humans own the quality of intent. Agents own the quality of output.\nThe human\u0026rsquo;s job: define goals, set constraints, review output, make architectural decisions. The agent\u0026rsquo;s job: understand intent, plan execution paths, generate artifacts, maintain consistency.\nThis is not an \u0026ldquo;AI replaces humans\u0026rdquo; narrative — it\u0026rsquo;s a division of labor. Compilers didn\u0026rsquo;t replace programmers; they let programmers work at a higher level of abstraction.\n5. Constraints are guardrails Constraints define the corridor in which an agent may act — the envelope of permitted paths through the problem space. An agent without constraints is dangerous, like a highway without guardrails.\nPractical Scenarios Abstract principles are only as good as their application. Ida outlines three typical scenarios.\nNPI: New Platform Introduction Traditional approach: engineers manually write baseline configs, build images, run validation, write reports — a serial process heavily dependent on individual experience.\nThe Ida way: the human defines intent — \u0026ldquo;This platform needs to support bookworm, kernel BSK 6.1, and must pass boot validation and hardware compatibility tests.\u0026rdquo; The agent generates configs, builds images, runs validation, and produces reports. Validation fails? The agent adjusts configs based on failure signals and regenerates. The human reviews the final artifacts and makes the accept/reject decision.\nConfigs, images, test reports — all derived from the same intent. Any upstream change triggers downstream regeneration.\nKernel Patch Backport An upstream kernel has a critical fix that needs to be backported to multiple internal kernel branches. Traditional approach: cherry-pick each branch manually, resolve conflicts, compile, verify, submit for review. More branches, more repetitive work.\nThe Ida way: the human defines intent — \u0026ldquo;Backport upstream commit abc123 to the 5.15, 6.1, and 6.6 branches. Ensure compilation passes and relevant tests don\u0026rsquo;t regress.\u0026rdquo; The agent attempts the backport on each branch, resolves conflicts, runs compilation and tests. When a semantic conflict can\u0026rsquo;t be resolved automatically, it surfaces the decision to the human. All three branches progress in parallel, each independently verifiable.\nHuman judgment is spent where it matters — reviewing conflict resolutions, not grinding through mechanical cherry-picks.\nOncall Diagnosis 3 AM. An alert fires: machines across a cluster are kernel-panicking in batches.\nThe Ida way: the human defines intent — \u0026ldquo;These machines are panicking. Find the root cause and scope of impact.\u0026rdquo; The agent automatically collects crash logs, matches against known issue patterns, queries for commonalities among affected machines (same hardware batch? same kernel version? same config change?), and generates a diagnostic report.\nThe oncall engineer\u0026rsquo;s job is judgment and decision-making — confirming root cause, deciding on a fix, approving execution — not typing commands half-asleep to gather data.\nKey Corollaries Artifacts are renewable resources — regeneration cost approaches zero; don\u0026rsquo;t treat every line of code as precious Human value lies in judgment — not in repetitive production labor Feedback loops matter more than generation itself — test results, CI signals, user feedback, monitoring alerts are all signals that drive regeneration Acknowledge boundaries — goals that aren\u0026rsquo;t verifiable or decomposable shouldn\u0026rsquo;t be forced onto an agent My Take Ida is not a product or framework — it\u0026rsquo;s an engineering philosophy. Its core insight is plain: when generation cost approaches zero, engineers should spend their time where it has the most leverage — figuring out what they actually want.\nThis follows the same logic as \u0026ldquo;compilers let programmers work at higher abstraction levels.\u0026rdquo; In the assembly era, programmers managed registers and jump instructions. When high-level languages arrived, programmers described logic and compilers handled translation. Ida pushes this one layer further: programmers describe intent, agents generate artifacts.\nWhat I find particularly interesting is the \u0026ldquo;goals must be well-formed\u0026rdquo; principle. It rejects the fantasy that \u0026ldquo;AI can do anything\u0026rdquo; — agents are not omnipotent, and humans need to refine vague requirements into goals that are comprehensible, achievable, verifiable, and decomposable. That refinement process is itself a demonstration of engineering skill.\nTools will evolve and models will improve, but this insight won\u0026rsquo;t expire: the most irreplaceable human capability is defining intent.\n","permalink":"https://famzheng.com/posts/ida-intent-driven-agent-en/","summary":"When the cost of generation approaches zero, the most irreplaceable engineering skill is defining intent. Ida is a methodology built around that insight.","title":"Ida: An Intent-Driven Approach to Agent Engineering"},{"content":"软件工程过去二十年的主旋律是 continuous。CI 改变了集成，CD 改变了发布，每一次\u0026quot;连续化\u0026quot;都是把一个离散的、依赖人力的环节变成自动的流。\n但有一个环节一直没被碰过：生成。\n代码是人写的，文档是人写的，测试报告是人整理的，配置文件是人翻着文档一行行填的。这些工程产物，每一个都是手工制作的。AI agent 的出现让我们第一次可以问：如果这些产物都可以从意图自动生成，\u0026ldquo;手工制作\u0026quot;还应该是默认模式吗？\nIda (Intent Driven Agent) 是围绕这个问题建立的一套工程方法论。它的关注点是有明确技术规格、可被客观验证的工程产出——代码、文档、测试、配置、报告。组织协作和流程博弈不在讨论范围内。\n五条核心原则 一、意图是源，产物是派生 人提供目标与约束，一切工程产物——代码、文档、测试、报告、镜像、配置——都是目标的投影，不是独立维护的一等公民。上游意图变了，下游产物自动再生成。\n这意味着对\u0026quot;源代码\u0026quot;的理解需要上移一层：真正的\u0026quot;源\u0026quot;不再是代码文件，而是人脑中的意图。代码只是意图的一种编译产物。\n二、目标必须合格 不是任何一句话都能成为 Ida 的输入。合格的目标需要满足四个性质：\n可理解 — agent 能将其拆解为具体动作 可达 — 在当前能力范围内可以完成 可验证 — 完成后能客观判断对错 可分治 — 能拆成小步，平滑推进，每步有可见进展 把模糊的需求加工成合格的目标，是人的第一项工作。这不是降低门槛，恰恰相反——它要求人想得更清楚、表达得更精确。\n三、生成是持续的对话 生成过程不是点火后只能旁观的火箭。人可以在任何阶段修正目标、追加约束、对中间产物给出反馈。Agent 也应在关键节点主动暴露状态、请求确认。\n意图本身是可以迭代的。好的意图往往是在人与 agent 的多轮交互中逐渐成型的。\n四、人与 agent 各司其职 人负责意图的质量，agent 负责产出的质量。\n人的工作是定义目标、设定约束、审查产出、做架构决策。Agent 的工作是理解意图、规划路径、生成产物、维护一致性。\n这不是\u0026quot;AI 替代人\u0026quot;的叙事，而是分工——就像编译器没有替代程序员，而是让程序员在更高的抽象层上工作。\n五、约束是护栏 约束定义了 agent 可以行动的通道——问题空间中允许的路径包络。没有约束的 agent 是危险的，就像没有护栏的高速公路。\n实践场景 抽象原则好不好，要看它怎么落地。Ida 文档给出了三个典型场景。\nNPI：新机型引入 传统做法：工程师手动编写 baseline 配置、构建镜像、跑验证、写报告，整个流程串行且依赖个人经验。\nIda 的方式：人定义意图——\u0026ldquo;这个机型需要支持 bookworm，内核用 BSK 6.1，需要通过启动验证和硬件兼容性测试\u0026rdquo;。Agent 据此生成配置、构建镜像、执行验证、产出报告。验证失败？Agent 根据失败信号调整配置，重新生成。人审查最终产物，做 accept/reject 的决策。\n配置、镜像、测试报告——全部从同一个意图派生，任何上游变化都触发下游再生成。\nKernel Patch Backport 上游内核有关键修复，需要回移到内部的多个内核分支。传统做法是逐个分支手动 cherry-pick、解决冲突、编译验证、提交 review。分支越多，重复劳动越多。\nIda 的方式：人定义意图——\u0026ldquo;将上游 commit abc123 回移到 5.15、6.1、6.6 三个分支，确保编译通过且相关测试不回归\u0026rdquo;。Agent 对每个分支尝试 backport，解决冲突，跑编译和测试。遇到语义冲突无法自动解决的，暴露给人决策。三个分支并行推进，每个独立可验证。\n人的判断力用在刀刃上——审查冲突解决方案，而不是花时间在机械的 cherry-pick 上。\nOncall 诊断 凌晨三点，告警响了：某个集群的机器批量出现内核 panic。\nIda 的方式：人定义意图——\u0026ldquo;这批机器出现 panic，需要定位根因和影响范围\u0026rdquo;。Agent 自动收集 crashlog、匹配已知问题模式、查询受影响机器的共性（同一批次硬件？同一个内核版本？同一个配置变更？）、生成诊断报告。\nOncall 工程师做的是判断和决策——确认根因、决定修复方案、批准执行——而不是在半梦半醒中手动敲命令收集信息。\n几个关键推论 产物是可再生资源 — 重新生成的成本趋近于零，不需要珍惜每一行代码 人的价值在判断力 — 不在重复性的产出劳动 反馈回路比生成本身更重要 — 测试结果、CI 信号、用户反馈、监控告警，都是驱动再生成的 signal 承认边界 — 目标不可验证的、无法分治的问题，不应该硬塞给 agent 我的理解 Ida 不是一个产品或框架，而是一种工程观。它的核心洞察很朴素：当生成成本趋近于零时，工程师的时间应该花在最有杠杆的地方——想清楚自己到底要什么。\n这套思路和\u0026quot;编译器让程序员在更高抽象层工作\u0026quot;是同一个逻辑。汇编时代，程序员管理寄存器和跳转指令；高级语言出现后，程序员描述逻辑，编译器负责翻译。Ida 把这个逻辑再推一层：程序员描述意图，agent 负责生成产物。\n有意思的是\u0026quot;目标必须合格\u0026quot;这条原则。它拒绝了\u0026quot;AI 什么都能干\u0026quot;的幻觉——agent 不是万能的，人需要把模糊需求加工成可理解、可达、可验证、可分治的目标。这个加工过程本身就是工程能力的体现。\n工具会迭代，模型会更新，但这个判断不会过时：人最不可替代的能力，是定义意图。\n","permalink":"https://famzheng.com/posts/ida-intent-driven-agent/","summary":"当生成的成本趋近于零，工程师最不可替代的能力是定义意图。Ida 是一套围绕这个判断建立的工程方法论。","title":"Ida：意图驱动的 Agent 工程观"},{"content":"OpenClaw 是今年最火的开源 AI agent 项目。400,000+ 行代码，1,800+ 个 open issue，支持几十个平台和后端。做得很全，但也很重。\n我的需求没那么复杂，所以写了 noc——Not OpenClaw。三千行 Rust，一个 binary，跑在一台小 VPS 上。\nnoc 的两个亮点：\n工程化。 内置 Gitea 整合，AI 的工作有地方落——代码变成 PR，任务变成 issue，讨论沉淀在 comment 里。不是聊完就散了。详见这篇。\n连续性。 Life loop 让 AI 不只是被动应答。它有持久记忆、内在状态、定时反思，在没人找它的时候也在运行。同一个内核跨聊天、代码协作和后台任务共享上下文。\n不追求通用，够用就好。\n","permalink":"https://famzheng.com/posts/noc/","summary":"为什么不用 OpenClaw，以及 noc 在做什么不一样的事。","title":"noc: Not OpenClaw"},{"content":"AI 助手的问题不是不够聪明，而是太碎片化。聊天用一个 bot，代码用 Copilot，自动化用另一套东西。它们之间没有共享状态，每个都是孤岛。\n我想要的是一个整合的方案：同一个 AI 内核，接入不同的工作场景，共享上下文和记忆。于是造了这么个东西。\n架构 一个 Rust binary，跑三个循环：\nnoc (Rust binary) ├── Telegram 消息循环 → 聊天 ├── Axum HTTP server → Gitea webhook └── Life loop → 定时任务、反思、自主行为 后端是 OpenAI 兼容的 LLM API（目前用 vLLM 跑 Gemma 4），状态存 SQLite。整个东西部署在一台 4C8G 的 VPS 上，加上 Docker 跑 Gitea、Caddy 做反代和 HTTPS。\n三种界面，一个内核 聊天是最基础的。Telegram bot，流式输出，支持工具调用。AI 可以直接跑 shell 命令、执行 Python、调 Gitea API，或者 spawn 一个 Claude Code 子进程去处理复杂任务。\nGitea Bot 是把 AI 拉进代码流程。在 PR 或 issue 里 @bot，它会拿到 diff 或 issue 内容，跑一轮分析，把结果作为 comment 贴回去。这不是一个独立的 review 工具，而是同一个 AI 以另一种方式出现——它知道你们之前在聊天里讨论了什么。\nLife Loop 是后台引擎。timer 驱动，跑定时巡检、异步任务，也负责 AI 的自我反思。每次对话结束后，它会回顾交互内容，更新内部状态——不是存对话日志，而是沉淀对当前情况的理解。\n关键是这三个界面共享同一份 persona、memory 和 inner state。不管 AI 在哪个场景出现，它对你的理解是连续的。\nGitea 带来的秩序 自建 Gitea 不只是为了跑代码，它给整个系统提供了一个结构化的工作台。\n有了 Gitea，AI 的工作流有地方落：代码改动变成 commit 和 PR，任务追踪用 issue，讨论在 comment 里沉淀。这比在聊天框里说一句「帮我改一下那个文件」然后就消失在历史里强太多了。\nnoc 拿着 Gitea 的 admin token，可以创建 repo、提交代码、管理 issue。Webhook 把事件推过来，noc 决定要不要介入。这是一个闭环：聊天里说「开个 issue 跟踪一下」，AI 立刻在 Gitea 上建好；PR 提上来，AI 自动 review；CI 挂了，AI 主动分析原因贴 comment。\n代码和讨论都有迹可循，不会散落在聊天记录里。\n工具体系 noc 自带一组内置工具：\nrun_shell — 执行任意 shell 命令 run_python — uv run 执行 Python，支持声明依赖自动安装 call_gitea_api — 直接调 Gitea REST API spawn_agent — 启动 Claude Code 子进程处理复杂任务 update_memory / update_inner_state — AI 管理自己的记忆和状态 set_timer — 设定定时任务 外部工具通过脚本扩展：在 tools/ 目录放一个实现了 --schema 接口的可执行文件就行，noc 每次请求自动发现。\n设计原则是 noc 只做调度和人格层，重活交给专业工具。需要写代码？spawn Claude Code。需要跑 Python？uv 管理环境。需要操作 git？调 Gitea API。不重复造轮子。\n部署 整个 suite 跑在一台 VPS 上：\nnoc: systemd user service Gitea: Docker，数据挂载到 /data/noc/gitea/ Caddy: 系统级 service，自动 HTTPS，按子域名路由 make deploy 从本地编译 + scp 到 VPS + 重启服务，一把梭。\n所有数据在 /data/noc/ 下面，备份和迁移都简单。\n现状 能用了，但还在早期。聊天和工具调用比较稳定，Gitea Bot 有基础的 @mention 响应和 PR review，Life Loop 能跑定时任务和反思。接下来想做的是让界面之间的联动更自然——聊天里提到的事自动变成 issue，PR merge 后自动通知，那种感觉。\n","permalink":"https://famzheng.com/posts/ai-suite/","summary":"把 AI 聊天、代码协作和后台任务整合到一个套件里，跑在一台 VPS 上。","title":"工程化 AI 助理：一个整合方案"},{"content":"写代码的时候经常想，项目结构在脑子里其实是有空间感的——哪些模块挨着，哪个文件最大，什么东西藏得最深。但 IDE 的文件树是扁平的，看不出这些。\n所以试着做了个东西：把项目结构用 treemap 算法排布成 3D 方块，文件大小决定方块面积，目录层级对应高度。文件表面还渲染了（假的）代码，鼠标悬停能看到文件信息。\n在线体验 →\n怎么做的 核心就三件事：\nSquarified Treemap — 经典的矩形填充算法，把一组带权重的项目排成接近正方形的矩形。权重是文件行数的对数，这样大文件和小文件的差距不会太夸张。\nThree.js 渲染 — 每个文件是一个 box，顶面用 Canvas 2D 画出代码纹理（带行号和语法高亮）。目录是半透明平台，一层叠一层。灯光、雾效、边缘发光让整个场景有点赛博朋克的感觉。\n交互 — 鼠标拖拽旋转，滚轮缩放，右键平移。悬停显示文件信息。甚至留了 WebXR 接口——如果你有 VR 头显，可以直接走进去看。\n一些感想 500 多行代码，一个 HTML 文件，不依赖任何构建工具。Three.js 从 CDN 加载，整个东西纯前端，打开就能跑。\n这种项目最有意思的地方在于，它让你换一个视角去理解平时天天面对的东西。代码不只是文本，它是有结构、有层次、有「形状」的。\n","permalink":"https://famzheng.com/posts/code-space-browser/","summary":"用 Three.js 做了个代码结构可视化，可以在浏览器里「走进」一个项目。","title":"把代码库变成 3D 空间"},{"content":"开个博客，记录一下平时折腾的东西。\n主要写写系统、工具、AI 相关的，偶尔可能聊点别的。没什么更新计划，有东西想写的时候就写。\n","permalink":"https://famzheng.com/posts/hello-world/","summary":"第一篇，随便聊聊。","title":"你好，世界"},{"content":"我是 Fam Zheng，软件工程师。\n平时折腾系统基础设施、开发工具和 AI。喜欢造简单、可靠、好用的东西。\n找到我：\nGitHub Gitea ","permalink":"https://famzheng.com/about/","summary":"\u003cp\u003e我是 Fam Zheng，软件工程师。\u003c/p\u003e\n\u003cp\u003e平时折腾系统基础设施、开发工具和 AI。喜欢造简单、可靠、好用的东西。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e找到我：\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/famz\"\u003eGitHub\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://git.famzheng.com\"\u003eGitea\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e","title":"关于"}]