[{"data":1,"prerenderedAt":442},["ShallowReactive",2],{"search-pool-zh":3,"post-zh-my-personal-history-with-television-media":205,"surround-zh-blog\u002Fzh\u002Fblog\u002Fmy-personal-history-with-television-media.md":435},[4,17,27,38,48,57,67,76,87,97,108,116,124,132,140,150,158,168,177,186,196],{"id":5,"slug":6,"title":7,"description":8,"date":9,"category":10,"tags":11,"fullText":16},"blog\u002Fzh\u002Fblog\u002Fantigravity-2-17-0-plan-before-code.md","antigravity-2-17-0-plan-before-code","Antigravity 2.17.0 发布：先规划再写代码","Antigravity 2.17.0 带来重量级更新：\u002Fplan 指令谋定而后动、独立 20,000 Token 规则预算、项目配置集中迁移及多项高频体验优化。","2026-09-25","coder",[12,13,14,15],"Antigravity","Plan","AI Agent","Release","antigravity 2.17.0 发布：先规划再写代码 antigravity-2-17-0-plan-before-code antigravity 2.17.0 带来重量级更新：\u002Fplan 指令谋定而后动、独立 20,000 token 规则预算、项目配置集中迁移及多项高频体验优化。 coder 程序员 antigravity plan ai agent release google antigravity 迎来了 v2.17.0 版本更新。 这次更新的核心逻辑非常明确——“plan before you build”（谋定而后动）。从规范 agent 的执行流，到彻底重构规则对上下文的占用，多项改动精准切中复杂工程场景的开发痛点。 本次更新的重点内容已为你梳理完毕 👇 1️⃣ 重磅特性：输入 \u002Fplan，先看方案再动代码 复杂任务中最怕 agent 盲目动手把代码改散。现在有了更稳妥的流程： 规划预览与修改 ：输入  \u002Fplan  后，agent 会先输出一份规划方案供你阅读和微调，确认无误后再动工编写代码。 计划审查策略（plan review policy） ：可在设置中选择三种策略：每步必审、仅在关键时刻由 agent 判断是否需要审查，或完全跳过直接执行。 2️⃣ 规则文件独立：20,000 token 专属预算 以往在项目中写了长篇的规范与规则，极容易把 skills、subagents 或 mcp 工具挤出上下文。 规则专属配额 ：工作区规则现在享有独立的 20k token 预算，不再抢占核心上下文空间。 超限优雅降级 ：超出预算的规则会自动折叠为“文件路径 + 描述”索引，agent 需要时才按需读取，避免生硬截断。 3️⃣ 重要变动：项目配置统一迁移 新配置路径 ：仓库的个性化配置正式迁移至  \u002F.gemini\u002Fconfig.json 。 废弃旧目录 ：旧的  .agents\u002Fsettings.json  已不再读取，若此前配置过  personal_customization_dir  等自定义目录，请记得手动迁入新文件。 4️⃣ 高频体验改进（部分精选） 命令面板切主题 ：新增快捷命令，无需打开 settings 即可直接切换深色\u002F浅色主题。 自定义 agent 支持 hooks ：markdown agent 可在 front matter 中通过  hooks:  引入钩子脚本，支持相对与绝对路径。 输入框粘贴体验 ：右键粘贴支持图片与富文本，保留 markdown 链接格式；覆盖选中附件粘贴也不会丢失文本。 插件与指令“产品化” ：slash 命令和内置 google 插件展示规范的产品名称与图标（如 chrome devtools、gemini api 等），告别冰冷的底层命令名。 更安静的链接展示 ：仅对需要操作或查看的内容（如新建的 review、启动的本地服务）弹出卡片，仅查阅过的链接静默存入侧边栏书签。 语言支持 ：新增  .cppm  文件的 c++ 语法高亮与专属图标。 5️⃣ 关键问题修复 \u002Frewind 快照回溯更准确 ：修复了回溯会取到过早历史快照的问题，现在严格取回退点后的最新快照或按步骤精确重放。 大文件\u002Fdiff 告别卡死 ：语法高亮与 diff 计算移出主线程；超过 100 kb 的文件自动回退为纯文本，保障界面流畅。 大项目扫描防超时 ：自定义规则、工作流扫描超时时间从 3 秒放宽至 15 秒，避免大型仓库误报加载失败。 \u002Fbtw 保持上下文 agent ：临时插入提问时，会自动沿用当前会话的 agent 配置，不再掉回默认 agent。 数学公式渲染修复 ：修复了  $$  行内同行  12pt  行间距导致吞字或多余美元符号的渲染 bug。 媒体保存修复 ：修复了 svg 与带编码信息的视频保存静默失败的问题，内联数据保存会自动匹配正确后缀。 💡  总结 antigravity 2.17.0 是一次非常成熟的“工程化演进”：用  \u002Fplan  规范了代码生产链路，用独立的规则 token 预算解决了上下文内耗。 如果正在使用 antigravity 处理中大型项目，推荐第一时间更新体验！",{"id":18,"slug":19,"title":20,"description":21,"date":22,"category":10,"tags":23,"fullText":26},"blog\u002Fzh\u002Fblog\u002Fgoogle-antigravity-2-16-0-new-features.md","google-antigravity-2-16-0-new-features","Google Antigravity 2.16.0 发布，这几个新功能太实用了","Google Antigravity 2.16.0 正式推送：原生支持 Windows WSL、Office 附件直接拖拽解析、子代理全面可视化及大项目极速扫描。","2026-09-23",[12,24,25,15],"Google","WSL","google antigravity 2.16.0 发布，这几个新功能太实用了 google-antigravity-2-16-0-new-features google antigravity 2.16.0 正式推送：原生支持 windows wsl、office 附件直接拖拽解析、子代理全面可视化及大项目极速扫描。 coder 程序员 antigravity google wsl release 就在今天，google antigravity 正式推送了 2.16.0 版本更新！这次的更新不仅大幅提升了大型项目的性能，还带来了几个直击开发者痛点的新功能。废话不多说，直接带大家速览本次更新的核心亮点！ 1. 终于来了！无缝接入 windows wsl 🐧 对于 windows 开发者来说，这是个期待已久的好消息。新版本在应用设置中新增了对 windows subsystem for linux (wsl) 的原生支持。你现在可以直接在应用内连接并切换到已安装的 wsl 发行版，标题栏会直观地显示当前激活的环境，开发与调试体验更加丝滑。 2. 原生读取 office 附件，拖拽即用 📄 告别繁琐的内容复制粘贴！从 2.16.0 开始，你可以直接将 word、excel 和 powerpoint 文档拖拽进对话框。得益于底层的更新，gemini 模型现在能够原生读取并解析这些文档内容，处理需求文档或数据表格的效率直线飙升。 3. 子代理（subagent）全面可视化 🤖 在复杂任务中，我们经常会调用子代理（subagent）。现在，所有的子代理调用都会以独立卡片的形式出现在对话流中。你可以实时看到它们是处于 running（运行中）、waiting（等待）还是 completed（已完成）状态。卡片上还新增了悬停停止按钮以及一键跳转侧边栏的快捷方式，彻底告别“黑盒”等待。 4. 性能飞跃与体验打磨 ⚡ 除了三大核心功能，这次更新在细节体验上也诚意满满： 大项目扫描“起飞” ：针对大型项目或网络挂载文件夹，自定义技能（skills）和配置文件的扫描速度有了质的飞跃——从过去的超过 1 分钟直接缩短到不到 1 秒！ 图片操作更顺手 ：终于支持右键直接复制或保存图片了！而且 svg 格式的图片现在可以完美复制到剪贴板，并直接粘贴到其他设计或代码应用中。 状态更透明 ：新的加载指示器会详细展示 agent 在准备回复时的具体动作（例如工具初始化进度），在网络波动导致模型重试时，还会显示带有尝试次数的实时倒计时。 总结 整体来看，antigravity 2.16.0 在跨平台开发环境（wsl）、办公文档解析以及运行状态可视化上迈出了一大步。大型项目加载速度的优化更是为日常开发省下了大量时间。建议大家立刻更新体验！",{"id":28,"slug":29,"title":30,"description":31,"date":32,"category":10,"tags":33,"fullText":37},"blog\u002Fzh\u002Fblog\u002Fantigravity-agent-default-permissions-deep-dive.md","antigravity-agent-default-permissions-deep-dive","深入介绍 Antigravity 新版本 Agent 默认权限设置","详解 Antigravity macOS\u002FLinux 终端沙箱新机制：Default 模式如何在保证安全的前提下减少频繁确认，平衡自主性与控制力。","2026-09-16",[12,34,35,36],"Agent","Security","Permissions","深入介绍 antigravity 新版本 agent 默认权限设置 antigravity-agent-default-permissions-deep-dive 详解 antigravity macos\u002Flinux 终端沙箱新机制：default 模式如何在保证安全的前提下减少频繁确认，平衡自主性与控制力。 coder 程序员 antigravity agent security permissions 我们正在改变 antigravity 中权限默认工作的方式！ **简要结论：**使用默认模式后，需要你确认的权限请求会更少。 随着 antigravity 更新 macos 和 linux 上的沙箱机制，命令现在默认会在沙箱中运行。只要访问的是项目文件夹中的内容，且不需要联网，就无需审批。 注：windows 目前仍使用现有的权限系统。 以前你需要在 turbo 模式和始终请求权限之间二选一；这次更新后，default 应该会成为一个更平衡的中间方案。 以下是各选项的说明： request review（请求审核） 默认所有命令都需要批准；命令不会在沙箱中运行。 读取和写入权限仅限工作区。 默认不允许网络访问；用户必须批准。 default（默认） 默认情况下，命令会在沙箱中运行，无需审批。agent 可以请求在沙箱外运行命令，但需要用户批准。 在沙箱中，读取和写入权限仅限工作区和系统临时目录。 沙箱中不允许网络访问；如需联网，agent 必须在沙箱外运行命令，并需要用户批准。 turbo 所有命令都会在沙箱外自动运行，无需批准。 可以读写磁盘上的所有文件。 agent 可以访问网络。 本次更新还允许你指定命令规则的适用方式： 沙箱关闭时， command  规则适用于所有命令；沙箱开启时，适用于沙箱内的命令。 沙箱开启时， unsandboxed  规则适用于沙箱外的命令。 permission presets（权限预设） 权限预设决定权限规则如何生效。你配置的  allow 、 deny 、 ask  规则会叠加在预设之上，并始终拥有更高优先级。 在 default 模式下，终端命令会在隔离的 terminal sandbox 中运行，访问范围限制在工作区和系统临时目录，且默认不能联网。当命令需要网络连接或主机资源时，agent 会请求在沙箱外运行；除非被  command(...)allow  规则覆盖，否则系统会要求你批准。 你可以在  settings → general → permission settings  中配置权限预设，也可以在  settings → projects  中按项目覆盖它。新项目默认使用  inherit global ，即跟随全局权限设置。 simon注：一些术语的中英文对照： antigravity 当前术语 建议中文 security preset 安全预设（比“权限预设”更贴近界面） default 默认模式 turbo mode turbo 模式 local permissions 本地权限 network access rules 网络访问规则 terminal commands 终端命令 commands outside sandbox 沙箱外命令 mcp tools mcp 工具 sandbox 沙箱 agent agent 另外，截止到目前，这个版本我还没有更新到。",{"id":39,"slug":40,"title":41,"description":42,"date":43,"category":10,"tags":44,"fullText":47},"blog\u002Fzh\u002Fblog\u002Fantigravity-cli-headless-remote-control.md","antigravity-cli-headless-remote-control","告别桌面客户端束缚：Antigravity CLI 1.2.0 的“无头远程控制”","Antigravity CLI 1.2.0 原生内置无头后台守护进程（Headless Daemon），支持脱离桌面客户端随时随地从浏览器远程操控开发机。","2026-09-10",[12,45,46,34],"CLI","Remote Control","告别桌面客户端束缚：antigravity cli 1.2.0 的“无头远程控制” antigravity-cli-headless-remote-control antigravity cli 1.2.0 原生内置无头后台守护进程（headless daemon），支持脱离桌面客户端随时随地从浏览器远程操控开发机。 coder 程序员 antigravity cli remote control agent 在处理大型重构、跑全套测试或跨项目迁移依赖时，ai agent 的执行往往需要几十分钟甚至数小时。以前要想在离开工位时用手机或浏览器接管任务，必须在电脑上开着 antigravity 2.0 桌面端，并在设置面板中保持 remote control 开启。 随着  antigravity cli 1.2.0  的发布，官方将这一能力原生内置到了终端工具中，带来了  无头远程控制（headless daemon） 。这意味着即使不启动桌面图形界面，甚至不保持终端窗口打开，你的开发机器也能作为一个常驻服务在后台待命，供你从任意设备的浏览器中随时连接与调度。 什么是“无头远程控制”？ “无头（headless）”指的是没有图形界面的运行模式。以往使用 cli 时，一旦终端窗口关闭或 ssh 会话断开，正在运行的进程就会中断。 1.2.0 引入的无头守护进程（daemon），本质上是将 antigravity cli 注册为 操作系统的系统级或用户级后台服务 ： linux ：注册为  systemd  用户服务。 macos ：注册为  launchagent 。 windows ：注册为计划任务（scheduled task）。 服务一旦注册启动，就会在后台建立与控制中枢的安全反向连接。哪怕你关闭终端窗口、锁屏，甚至系统遭遇异常崩溃，服务都能自动恢复运行。 三条核心命令搞定运维 操作无头服务不再需要手写 systemd 单元文件或 macos plist 配置文件，cli 提供了三个极简子命令： 1. 注册并启动后台常驻： agy remote-control start 在已经完成登录的终端中运行： agy  remote-control  start\n 系统会自动安装对应的系统服务并立即拉起进程。 如果你的多台工作站共用同一个账号，建议在启动时加上自定义实例名称，方便在网页端区分： agy  remote-control  start  --name  \"workstation-mac\"\n (如果不指定  --name ，系统会自动分配一个类似  my-machine-distant-plume  的易记名称)。 2. 查看运行状态与机器名： agy remote-control status 随时可以通过该命令检查服务是否正常在跑、当前的连接状态以及当前机器的实例标识名： agy  remote-control  status\n 3. 停止并彻底注销： agy remote-control stop 当你不再需要这台机器在后台待命时，执行以下命令即可停止守护进程，并将其从系统服务管理器中彻底反注册： agy  remote-control  stop\n 如何在浏览器端连接与使用？ 无头服务跑起来后，使用流程和桌面端 remote control 完全一致： 登录控制台 ：在手机、平板或任意电脑的浏览器中打开  https:\u002F\u002Fantigravity.google.com\u002F 。 账号对齐 ：使用与命令行相同的 google 账号登录。 选择机器 ：在实例列表中找到刚刚配置的机器名称（如  simonmacbookair-local-rising-bolt ）。 远程操控 ：连接成功后，你可以在网页端直接发起新任务、查看当前上下文、审查代码 diff 与产物，并在 agent 请求工具授权时直接远程点击确认。 (注：如果在手机端使用，建议将该网页“添加到主屏幕”，当后台任务完成或等待人工输入时，能接收到推送通知)。 关键细节与注意事项 认证分离 ：守护进程使用的是 antigravity cli 的登录凭据（ agy  登录状态），与同一台机器上 antigravity 桌面编辑器的登录态是各自独立的。 不同操作系统的常驻生命周期 ：\n linux ：开机即自启，无论是否有用户登录会话，都会在后台保持常驻。 macos ：在用户登录进入桌面时启动，退出登录（sign out）后暂停，下次登录自动恢复。 windows ：如果以管理员权限运行  start ，可实现开机免登录自启；普通终端运行则在用户登录后启动。 改名生效方式 ：如果想修改实例名称，可以直接重复执行带新名字的  agy remote-control start --name \"new-name\" ，或者修改配置文件  ~\u002F.gemini\u002Fconfig\u002Fconfig.json  中的  cliremotecontrolhostname  字段，随后重新执行  start  重启服务即可。 cli 1.2.0 对无头远程控制的集成，让你的本地开发环境真正变成了一台随时随地可调用的“私人 ai 计算节点”，既保留了本地环境的工具链优势，又彻底解除了被实体工作台绑定的限制。 html pre.shiki code .sscjk, html code.shiki .sscjk{--shiki-default:#6f42c1;--shiki-dark:#b392f0}html pre.shiki code .szznc, html code.shiki .szznc{--shiki-default:#032f62;--shiki-dark:#9ecbff}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html pre.shiki code .sj4cs, html code.shiki .sj4cs{--shiki-default:#005cc5;--shiki-dark:#79b8ff}",{"id":49,"slug":50,"title":51,"description":52,"date":43,"category":10,"tags":53,"fullText":56},"blog\u002Fzh\u002Fblog\u002Ffrontier-engineering-ten-core-principles.md","frontier-engineering-ten-core-principles","Frontier Engineering：10 条核心原则","前沿软件工程宣言：软件开发者正在分为两类。10 条原则带你从打字员转变为系统架构师，建立高杠杆的 AI Agent 研发体系。",[54,14,55],"Frontier Engineering","软件工程","frontier engineering：10 条核心原则 frontier-engineering-ten-core-principles 前沿软件工程宣言：软件开发者正在分为两类。10 条原则带你从打字员转变为系统架构师，建立高杠杆的 ai agent 研发体系。 coder 程序员 frontier engineering ai agent 软件工程 原文来源 ： https:\u002F\u002Fkiro.dev\u002Ftopics\u002Ffrontier-engineering\u002F 术语说明 ：文中保留  agent 、 prompt 、 context 、 steering file 、 skill 、 mcp 、 vibe coding 、 ci 、 pr  和  guardrail  等 ai 与工程术语。 概述与宣言 软件开发者正在分成两类：一类人改变了自己与 ai agent 协作的方式，另一类人只是换了编程工具。如今，ai agent 已经能够自主编写代码、运行测试、修复失败并继续迭代，而且越来越能在没有人类介入的情况下连续工作数小时。开发者的工作也随之发生了变化。那些实现生产力跃升的开发者，并不是用了比别人更好的编程工具，而是采用了不同的工作方式：他们不再直接构建软件，而是构建一套能让 agent 完成软件开发的工作体系。 本指南写给一线从业者（管理者另有指南）。如果你已经在使用 ai 编程助手，交付速度却没有明显提升，这篇指南会告诉你需要改变什么。先提醒一句：这是一项工程投资，不是打开一个开关就能完成的事。你需要花几周时间培养直觉、编写  steering file 、重构代码库，并学习如何把工作拆解给 agent。如果你不准备改变工作流程，却期待立刻见效，结果会让你失望。最初几周可能反而更慢，之后速度才会显著提升。 10 条原则一览 你是架构师，不是打字员 尽可能延长 agent 的工作时间，减少你的介入 为 agent 建设代码库 为 agent 建立快速反馈循环 执行成本很低，方向决定一切 把代码当作可丢弃的产物 用要求人类的标准要求 ai 产出 信任边界，而不是 agent 让 agent 参与所有工作，而不只是写代码 持续调校你的 agent 工作体系 frontier engineering 不是 vibe coding frontier engineering 不是 vibe coding，也不是把  prompt  粘进聊天框后碰运气。它是一套严谨、有章法的工程实践，把传统工程纪律与 ai agent 带来的杠杆效应结合起来。长远来看，你需要持续锻炼的能力，是管理自己的注意力。随着 agent 接手越来越多的执行工作，你要承担同时在多个 agent 之间切换  context  的认知负荷；一切加速时，仍要有意识地守住质量标准；吃饭或到了深夜，还得克制自己，不要反复查看 agent 的进度。你的工作变成了不断判断：什么需要你关注，什么不需要。 frontier engineering 仍处于早期采用阶段。现在还没有多少开发者以这种方式工作，这套实践也仍在成熟：怎样审查 agent 的产出最有效，怎样为 agent 而不是人类设计工具和测试基础设施，这些问题都还没有公认答案。因此，这种工作方式仍然依赖直觉：什么该交给 agent，任务范围该怎么划定，又该在什么时候介入。这些直觉来自实践，也来自最初几周编写  steering file 、重构代码库和学习拆解任务的过程。一旦掌握了这种工作方式，你的交付速度会显著提高，也能着手完成过去无暇顾及的工作：原本超出范围的功能、迟迟没有进行的架构调整，以及一直没空补上的测试和工具。此后，收益还会继续累积：agent 的能力每提升一步，都建立在你已经积累的经验之上。这种工作方式仍在形成，而现在采用它的开发者也正在参与定义它。从今天开始改变你的工作方式。 01. 你是架构师，不是打字员 这份工作的重点不再是写代码，而是写清楚意图。我们看到，前沿开发者亲手编写的代码不到其产出总量的 1%，其余代码来自他们指挥、引导和审查的 agent。 工作可以归结为两件事：定义什么算“完成”（包括需求、约束和验收标准），以及验证产出是否符合你的意图。 把意图写清楚并不是新要求，但现在已经不能省略。你要说明期望的行为、需要考虑的边界情况，以及如何验证结果是否正确。例如，“给这个 api 加上身份认证”并不是清楚的意图；你需要说明哪些角色能访问哪些 endpoint、token 过期时如何处理，以及怎样测试未授权访问。然后让 agent 编写代码。 过去，你的大部分时间用于写代码；现在，这些时间会用来明确意图、确定方向，并有针对性地审查 agent 的产出。 02. 尽可能延长 agent 的工作时间，减少你的介入 许多开发者始终和编程助手待在同一个循环里：给 agent 一条  prompt ，等 60 秒，拿到代码，手动测试，再把错误粘回聊天框，然后重复这一过程。这样不可能获得很高的开发速度。 前沿开发者会把执行时间更长的任务交给 agent，并在任务中写明验证步骤：“实现这个功能，编写测试并运行，确保测试通过，新代码的覆盖率达到 90%。”随后，agent 可以工作 30 分钟甚至更久，而你去处理别的事情。agent 中途会犯错，这很正常。让它继续循环、自我修正，逐步收敛到正确结果。 让多个 agent 并行处理持续到来的任务，并异步审查它们的产出。现在限制生产力的不再是打字速度，而是你能让多少个 agent 同时承担有意义的工作。 随着工具逐渐完善，你对这种方式也更有信心，可以进一步延长 agent 的运行时间：让它连续工作数小时或通宵，也可以让 agent 启动其他 agent，第二天早上再检查结果。目标是逐步把自己移出执行循环，最终只负责确定方向和验证结果。 03. 为 agent 建设代码库 agent 的表现很大程度上取决于它所面对的代码库。先打好那些对人类也有帮助的基础：完整的 readme 和架构文档、能够说明预期行为的测试、清晰的模块边界、强类型，以及速度快、错误信息明确的构建流程。面对大型遗留代码库时，应当一次整理一个模块，并把 agent 的工作范围限制在已经准备好的模块内，而不是直接让它处理整个代码库。 如今，这些投入的回报远高于以往，因为新的人类成员只需要完成一次 onboarding，而 agent 每个 session 都要重新 onboarding。人类记在脑中的信息，需要明确提供给 agent：用  steering file  说明约定和编码标准；通过  skill  按需加载特定任务的操作流程；用脚本自动设置环境；通过命令行工具和 mcp server 获取  context 、执行操作。 让 agent 把自己的工作记录下来，供后续 session 使用。agent 应当记录设计决策，并在代码中留下足够的注释，作为持久记忆。这样，下一个 agent session 继承的不只是代码，还有代码背后的理由。 04. 为 agent 建立快速反馈循环 如果 agent 不能在本地运行测试，并在你查看代码之前自行修正，那么瓶颈就是你。前沿开发者会投入精力，把验证流程做得快速、本地化且可自动执行，让 agent 能在紧凑的循环中反复测试。 agent 应当能够使用代码检查工具和单元测试，能够通过浏览器渲染界面并直观检查 ui 改动，能够使用依赖服务的本地 mock 进行集成测试，也能够在笔记本电脑上启动完整技术栈，执行端到端测试。如果你会使用某项工具验证自己的工作，agent 也应当能够使用它。这样它就能自行验证，而不需要你在不同工具之间复制粘贴输出。 属性测试在这里尤其有用：它能验证实现是否符合你的意图，还能发现一些 agent 不会主动为其编写具体测试用例的边界情况。agent 应当能够自行验证工作、发现失败并加以修复，不需要你留在循环中。 没有这些投入，代码生成得更快，只会带来更多失败的构建和缺陷。有了这些能力，代码库的整体质量反而会提高，因为 agent 的验证往往比许多人实际执行得更全面、更一致。 05. 执行成本很低，方向决定一切 当代码一个下午就能写完，困难的部分就不再是实现，而是判断该解决什么问题、该构建什么，以及什么时候应该改变方向。实现细节的修改成本很低，但系统设计、api 契约、依赖关系和架构取舍仍然代价高昂。把精力放在这些影响长久的决策上。 在设计阶段，可以把 agent 当作头脑风暴的伙伴：让它研究可选方案、探索不同路径，并找出你思路中的漏洞。如果两种设计都可行，可以让 agent 分别制作原型并进行比较。过去只能靠争论决定的问题，现在可以用证据来判断。 方向确定以后，采用 spec 驱动的开发方式：先与 agent 一起写出清楚的 spec 和需求，减少它开始生成代码之前的歧义。如果只给 agent 一个含糊的  prompt ，它会自行决定如何取舍，而你撤销这些决定花费的时间，可能比跳过 spec 省下的时间更多。 迭代过程中，把注意力放在最重要的问题上：架构能否承受真实负载，原先的设计取舍是否需要重新评估，以及当前产物是否已经可以交到用户手中。 06. 把代码当作可丢弃的产物 如今，代码的成本很低。你需要不断判断正在构建的东西是否值得发布，以及它是否值得后续的运维和维护成本。现在，你可以用一天做出原型，然后选择放弃；也可以用两周把产品做到接近可发布的状态，发现方向不对后再重新开始。 过去，丢弃代码很难，原因有两个：代码是自己花几个月写出来的，所以很难割舍；重新开始，又意味着再花几个月。现在，这两个原因都不复存在。重要的是交付正确的东西，而不是勉强把初稿送进生产环境，也不是因为已经投入了成本，就回避必要的架构调整。 不再有用的代码，就把它丢掉。agent 可以在当天结束前构建出下一个版本。 边界处的测试是例外。单元测试会和代码一起被丢弃，但那些让重新开始仍然安全的测试需要保留：验证行为的端到端集成测试、验证不变量的属性测试，以及验证大规模性能和并发能力的负载测试。它们共同构成了任何重写版本都必须满足的契约。 07. 用要求人类的标准要求 ai 产出 只有速度，没有质量，只会增加生产环境中的风险。无论代码由谁或什么生成，只要以你的名义发布，责任就在你。刚开始时，这意味着要逐行审查 agent 的产出，逐渐弄清模型擅长什么、容易在哪些地方出错，从而建立信心。 时间久了，逐行阅读所有代码无法扩展到更大的工作量，因此你需要构建一个 ai reviewer 来分担审查工作，检查团队在意的问题，例如正确性、安全性、可维护性、测试质量和常见缺陷模式。在创建 pr 之前，先用 ai reviewer 检查本地改动，然后在 ci 中再运行一次。ai reviewer 逐渐成熟后，可以让它处理前几轮反馈。 把人的注意力放在最擅长判断的问题上，例如设计和架构是否合理，改动会怎样影响上下游系统，以及安全边界是否可靠。 不要让 agent 的工作循环止于合并。让它监控部署、验证生产环境中的实际行为；如果出现回退或异常，就自动开始处理修复。对结果负责，意味着跟进一项改动进入生产环境的全过程，而不是在 pr 阶段停下。 08. 信任边界，而不是 agent 要让 agent 长时间自主运行，就需要不依赖人工监看的  guardrail 。不要接受这样的虚假二选一：要么任由 agent 在你的电脑上不受限制地运行，要么对每一次  tool call  都点击“接受”。更好的做法是把 agent 的权限限制在它实际需要的文件、工具、网络和凭据内，然后让它在无需监督的情况下运行。 一开始把范围收紧，随着你对这些限制更有信心，再逐步扩大权限，最终只对无法撤销的操作设置确认。对生产环境尤其要谨慎：除非你明确、审慎地授权，否则 agent 不应拥有生产账号或部署凭据。 再加入确定性的检查，捕获普通测试不容易发现的问题：用静态应用安全测试发现漏洞，用凭据扫描发现泄露的密钥，并通过自动推理，以数学方式验证 agent 的产出是否符合你的意图。每自动化一项  guardrail ，你就少一个必须留在循环中的理由。 09. 让 agent 参与所有工作，而不只是写代码 建立起前面提到的习惯和基础以后，可以把同样的做法用到各类工作中。过去需要一周完成的设计文档，现在一个下午就能完成；过去耗时数小时的运维调查，现在几分钟就能完成。进度更新、sprint 总结、oncall 报告和文档，都可以采用同一套流程。 提供  context ，定义预期结果，让 agent 起草，然后在对外分享之前进行审查和修改。 真正的提速来自把 agent 用在整个开发生命周期中：规划、开发、测试、部署和运维。这份宣言里的原则同样适用于这些 agent：给出清楚的意图、快速的反馈循环和受限的访问权限。pipeline agent、oncall agent、文档 agent 和第三方 agent 应当共享大部分基础配置与  context 。给它们相同的  steering file  和工具，让它们无论执行什么任务，都能保持一致的行为。 10. 持续调校你的 agent 工作体系 每当 agent 走错方向，或不必要地把你拉回执行循环时，都问问自己：怎样防止同样的事情再次发生？解决办法可能是在  steering file  中增加一条规则，用  skill  记录它没有正确执行的流程，用命令行工具把手动步骤自动化，用 mcp server 获取合适的  context ，或者扩大它对某项此前无法访问的工具或系统的权限。agent 的每次失误和打断，都是进一步提高其自主性的机会。 这就是 frontier engineering 新的日常习惯：你不仅在构建产品，也在不断改进那套构建产品的系统。 这种习惯会逐渐产生复利。最初，agent 只有在你明确给出  prompt  后才会运行，而且经常需要你介入。随着  steering file  和工具逐渐成熟，agent 会变得更加自主，能够在后台运行：无需你发起任务，就主动发现并修复缺陷、清理技术债、改善代码质量。 随着模型改进，新的 agent 可以清理旧模型生成的内容。新模型发布时，重新检查过去为了弥补旧模型弱点而采用的变通方案是否还有必要。 steering file  和工具都是持续演进的产物，其变化速度会和模型一样快。",{"id":58,"slug":59,"title":60,"description":61,"date":62,"category":10,"tags":63,"fullText":66},"blog\u002Fzh\u002Fblog\u002Ffixing-macos-high-cpu-usage-in-dasd-process-with-antigravity.md","fixing-macos-high-cpu-usage-in-dasd-process-with-antigravity","Antigravity 帮助修复 macOS 中 dasd 进程 CPU 占用高的 Bug","今天，我的 Mac（运行最新的 macOS 27.0 beta8）开始变得迟钝，打开活动监视器一查，一个名叫 dasd 的系统进程死死吃满了 90%～120% 的单核 CPU...","2026-09-08",[64,65],"beta","macos","antigravity 帮助修复 macos 中 dasd 进程 cpu 占用高的 bug fixing-macos-high-cpu-usage-in-dasd-process-with-antigravity 今天，我的 mac（运行最新的 macos 27.0 beta8）开始变得迟钝，打开活动监视器一查，一个名叫 dasd 的系统进程死死吃满了 90%～120% 的单核 cpu... coder 程序员 beta macos 今天，我的 mac（运行最新的 macos 27.0 beta8）开始变得迟钝，打开活动监视器一查，一个名叫  dasd  的系统进程死死吃满了 90%～120% 的单核 cpu。我搜索了一下，没有找到合适的答案。使用 google antigravity 一路追踪，结果抓到了一个令人哭笑不得的**“苹果工程师写出跨时区死循环”**的大瓜。 不想读太多的直接用这行命令： defaults write com.apple.appstored arcadepayoutresetdate \\\n  -date \"$(date -v+3d -u +\"%y-%m-%dt%h:%m:%sz\")\" && \\\n  killall appstoreagent\n 以下是 google antigravity 的解决过程 结论与当前状态 (bluf) dasd  持续占用 90%~99% cpu  并非正常的系统开机维护任务，而是  appstoreagent （app store 后台服务）陷入了极高频的任务调度死循环 。 该问题已经定位并 已完成修复 ， dasd  的 cpu 占用已从  98.1% 降至 0.0% ，系统恢复正常，无需重启电脑。 根本原因分析 通过抓取系统统一日志（unified logging system）与进程调用链路，发现了确凿的死循环证据： 死循环任务 ： com.apple.appstored.arcaderesetpo （apple arcade 收益指标重置任务）。 逻辑缺陷 ：\n 当前时间为下午，但  com.apple.appstored  偏好设置中的  arcadepayoutresetdate  被固定在今天凌晨： 2026-09-06 00:00:00 +0800 （过去的时间）。 appstoreagent  执行完重置后，未将其递增到下一个周期（次日），而是继续使用已经过期的  2026-09-06 00:00:00  作为新执行时间重新注册。 dasd （duet activity scheduler）收到调度请求后，发现预定时间早于当前系统时间，判定为超时，立刻下发调度（ running immediately on submission ）。 结果： 每秒触发超过 400 次调度与进程通信 ，导致  dasd  持续跑满单核 cpu。 现场日志证据 appstoreagent: [arcadepayoutreset] payout metrics reset with current payout reset time: 2026-09-06 00:00:00+0800\nappstoreagent: [arcadepayoutreset] reset with reason: rescheduling\nappstoreagent: [arcadepayoutreset] using new date: 2026-09-06 00:00:00+0800 with reason: rescheduling\nappstoreagent: [arcadepayoutreset] activity not scheduled; submitting request\ndasd:          submitting: 501:com.apple.appstored.arcaderesetpo\ndasd:          running immediately on submission\ndasd:          requesting start: 501:com.apple.appstored.arcaderesetpo\n 采取的解决措施与验证 已通过将偏好项中的调度时间推进至次日，并平滑重启  appstoreagent  打破该死循环： 执行命令 ： defaults write com.apple.appstored arcadepayoutresetdate -date \"2026-09-06t16:00:00z\" && killall appstoreagent 验证结果 ：\n top  \u002F  ps  监测确认： dasd （pid 404）cpu 占用立即降至  0.0% 。 appstoreagent  重新启动后正常挂起，不再以 400+ 次\u002F秒的频率刷屏日志。 经过 google antigravity 一顿操作，cpu 占用下来了。",{"id":68,"slug":69,"title":70,"description":71,"date":72,"category":10,"tags":73,"fullText":75},"blog\u002Fzh\u002Fblog\u002Fantigravity-2-12-0-boost-command.md","antigravity-2-12-0-boost-command","Antigravity 2.12.0 新增了 \u002Fboost 命令","深度解析 Antigravity 2.12.0 新增的 \u002Fboost 深度攻坚命令，对比 \u002Fteamwork-preview 多智能体协同在定位、流程与工作模式上的核心差异。","2026-09-03",[12,14,74],"Boost","antigravity 2.12.0 新增了 \u002Fboost 命令 antigravity-2-12-0-boost-command 深度解析 antigravity 2.12.0 新增的 \u002Fboost 深度攻坚命令，对比 \u002Fteamwork-preview 多智能体协同在定位、流程与工作模式上的核心差异。 coder 程序员 antigravity ai agent boost \u002Fboost  与  \u002Fteamwork-preview  都是 antigravity 中用于处理复杂任务的高阶调度机制，但两者的 设计定位、协作形态和前置流程 有本质区别： 1. 核心定位与使用场景 维度 \u002Fboost  (深度攻坚 \u002F 强化委托) \u002Fteamwork-preview  (多智能体协同 \u002F 团队项目) 主要定位 纵向深挖 ：针对高复杂度、需要深度思考与严苛验证的单项硬核任务。 横向协作 ：针对跨模块、大体量、需要多角色分工或超大规模并行探索的系统级项目。 适用场景 • 复杂的代码重构、困难的算法实现 • 疑难 bug 根因定位、死锁\u002F性能排查 • 单点深度调研与严谨技术选型 • 完整系统从 0 到 1 构建（如开发一个编译器、复杂 web 应用） • 难解数学定理证明与大规模并行推演（支持多 agent 并行） • 完整的技术文档审阅评估 底层智能体形态 调度者协调特定攻坚角色： •  deepcoder （专注代码实现） •  deepinvestigator （专注根因分析与验证） 依据任务形态路由的多 agent 团队： • 文档评审组 \u002F 形式化证明管线 • 大规模并行探索团队（可扩展到数十\u002F上百 agent） • 模块化开发与对抗性审核团队 2. 工作流程与交互方式的区别 \u002Fboost ：快速路由与闭环打磨 无需冗长的前置对齐 ：通常由 orchestrator 自动决定进入 solo 模式还是 delegation 模式。 高保真任务传递 ：原汁原味地将用户需求派发给攻坚 subagent，无需繁重的需求拆解模板。 多轮验证循环 ：worker 完成后，调度者会主动挑错、审查未满足条件，并在必要时发起追问与额外轮次，直到完全满足标准。 \u002Fteamwork-preview ：严谨的提示词工程与契约验收 两阶段工作法 ：必须先经历  (1) 需求打磨与契约拟定 ，再  (2) 正式委派启动 。 强制防“伪通过”（anti-self-certification） ：通过交互式流程建立客观的测试基准（acceptance criteria）和约束，防止 agent 团队自己给自己打满分并过早交卷。 工件跟踪 ：全程维护  prompt_draft.md ，在用户最终确认批准前不会盲目启动多智能体系统。 3. 一句话总结与选择建议 选  \u002Fboost ：当你有一个 具体的硬骨头要啃 （复杂的实现、难排查的 bug、深度的验证调研），希望让专业模型深入推演、反复检查代码质量时使用。 选  \u002Fteamwork-preview ：当你想要 立项做一个完整的复杂系统\u002F项目 ，或者做大规模并行推演，需要先梳理好需求边界与验收标准，再交由一个多 agent 团队分工搞定时使用。",{"id":77,"slug":78,"title":79,"description":80,"date":81,"category":10,"tags":82,"fullText":86},"blog\u002Fzh\u002Fblog\u002Fgemini-3-8-flash-stealth-release.md","gemini-3-8-flash-stealth-release","Gemini 偷偷上线了 3.8 Flash，谷歌最近的版本更新有点太快了","Gemini 网页端静默灰度上线 3.8 Flash。一个月内小版本连跳两级，解析谷歌大模型发版策略与 Flash 快速迭代逻辑。","2026-09-02",[83,24,84,85],"Gemini","LLM","AI","gemini 偷偷上线了 3.8 flash，谷歌最近的版本更新有点太快了 gemini-3-8-flash-stealth-release gemini 网页端静默灰度上线 3.8 flash。一个月内小版本连跳两级，解析谷歌大模型发版策略与 flash 快速迭代逻辑。 coder 程序员 gemini google llm ai 今天随手在网页端问了 gemini 一句“你现在是什么模型”，它的回答直接跳出了  gemini 3.8 flash 。 有趣的是，界面右下角依然显示的是“flash”，顶部菜单和模型选择标签里也只写着 3.7。当我追问它“为什么前端还显示 3.7”时，它倒是把底层逻辑解释得明明白白：前端 ui 的缓存和文案还没同步，但后端的路由分流已经悄悄切到了新模型。 没有推文官宣，没有博文预热，属于典型的静默灰度上线。 这张截图说明了什么？ 看模型自己的回答，其实非常符合现代 web 服务的灰度发布流程： 前端与后端脱节 ：ui 上的名字是静态配置或发版节奏较慢的资源，而后端模型的 ab 测试和路由切换可以实时调整。 渐进式放量 ：如果你现在去问，可能有的会话依然是 3.7，新开一个对话或者被命中了实验桶，就会拿到 3.8。 这次升级依旧落在了  flash  上。作为轻量、快速、便宜的模型线，flash 现在的定位就是做日常任务和快速响应的主力。谷歌把新调整直接先放到 flash 上跑，用真实的流量来验证效果。 gemini 最近的发布频率：快得有点反常 回顾一下最近一两个月 gemini 的动作，节奏明显变了： 7 月底 ：gemini 3.6 flash 上线。 8 月中旬 ：推出了 gemini 3.7 flash，中间只隔了三周左右。 9 月初 ：现在 gemini 3.8 flash 已经开始在生产环境灰度，距离 3.7 的发布甚至还不到三周。 一个月出头的时间，次级版本号从 3.6 一路跳到 3.8。这种高频的发版节奏说明了两件事： 版本号的意义在变淡 \n以前大模型发一个“点版本”（如从 3.0 到 3.5），通常伴随着重大的架构调整或跨越式的性能提升。现在的 .x 更像是一次常规的双周敏捷迭代，改了对齐、补了数据、修了部分特定领域的短板，测试没问题就直接推上线。 flash 成了快速迭代的试验田 \n相比参数量巨大、调用成本高的 pro 或 ultra 模型，flash 拥有极低的推理延迟和成本。谷歌显然选择把高频改动先放到 flash 上快速试错，让它承担日常最大量的交互。 对于日常写代码、做简单自动化或当搜索工具用的开发者来说，这种“频繁的小修小补”其实体验更平滑。你可能感知不到某一天突然天翻地覆的变化，但模型在默默地换代。 你可以去自己的网页端问问它现在的版本，看看你被分在哪个灰度池里了。",{"id":88,"slug":89,"title":90,"description":91,"date":92,"category":10,"tags":93,"fullText":96},"blog\u002Fzh\u002Fblog\u002Ffix-antigravity-chrome-devtools-mcp-permission-prompt.md","fix-antigravity-chrome-devtools-mcp-permission-prompt","彻底解决 Google Antigravity 频繁提示 Chrome DevTools MCP 授权的问题","在使用 Google Antigravity 进行前端调试与网页自动化时，配置整服务级权限免除 Chrome DevTools MCP 频繁弹窗确认的实战指南。","2026-08-23",[12,94,95,14],"Chrome DevTools","MCP","彻底解决 google antigravity 频繁提示 chrome devtools mcp 授权的问题 fix-antigravity-chrome-devtools-mcp-permission-prompt 在使用 google antigravity 进行前端调试与网页自动化时，配置整服务级权限免除 chrome devtools mcp 频繁弹窗确认的实战指南。 coder 程序员 antigravity chrome devtools mcp ai agent 在使用 google antigravity（或 gemini 智能体环境）进行前端调试、网页自动化测试时，很多人会配置并启用 chrome devtools mcp 插件。 但在实际使用中，经常会遇到一个让人烦躁的体验： 明明每次弹窗都选了“yes, and always allow”（永久允许），但每跑两步还是会频繁跳出权限确认弹窗。 本文记录一下这个问题的原因和一行配置彻底解决的方法。 现象描述 智能体在执行网页操作时，界面频繁弹出确认窗口： allow using this mcp tool?\nchrome-devtools\u002Flist_network_requests\n\n1. yes, allow this time\n2. yes, and always allow in this conversation\n3. yes, and always allow in this project\n4. yes, and always allow\n5. no (tell the agent what to do instead)\n 即使你选了  4 （全局永久允许），下一个操作调用控制台、截图或点击元素时，弹窗依然会再次出现。 为什么选了“永久允许”还是会弹窗？ 原因在于权限粒度。 当你选择  4. yes, and always allow  时，antigravity 默认只把 当前被调用的具体子工具 加入白名单，例如： mcp(chrome-devtools\u002Flist_network_requests) mcp(chrome-devtools\u002Fevaluate_script) 而 chrome devtools mcp 实际上包含了 20 多个独立的工具（ click 、 fill 、 hover 、 navigate_page 、 take_snapshot 、 get_console_message 、 lighthouse_audit  等）。智能体在完成一个多步骤任务时，会根据上下文调用不同的子工具；只要遇到一个此前没被单独授权过的工具，系统就会再次弹窗确认。 解决方案：配置 mcp 服务级全局授权 解决方式非常直接：在权限列表中配置 整个 mcp 服务 ，而不是单个子工具。 修改步骤 打开全局配置文件：\n 路径： ~\u002F.gemini\u002Fconfig\u002Fconfig.json 找到  usersettings.globalpermissiongrants.allow  数组。 在数组中添加  \"mcp(chrome-devtools)\" 。 示例配置： {\n   \"usersettings\" : {\n     \"globalpermissiongrants\" : {\n       \"allow\" : [\n         \"mcp(chrome-devtools)\" ,\n         \"command(git log)\" ,\n         \"command(npm run)\"\n       ]\n     }\n   }\n }\n 规则对比 授权格式 作用范围 适用场景 mcp(chrome-devtools\u002Fnavigate_page) 仅允许单个子工具 严格限制危险操作（如仅允许只读类工具） mcp(chrome-devtools) 允许该 mcp 服务下的 所有 工具 完全信任该服务，免除所有子工具弹窗 补充技巧 对其他 mcp 服务通用 ：如果你接入了其他自建或第三方 mcp 服务（如本地命令执行、ssh 管理等），同样可以使用  mcp(\u003Cserver-name>)  的语法实现整服务免确认。 项目级独立配置 ：如果不希望全局开启，也可以在项目对应的配置文件（ ~\u002F.gemini\u002Fconfig\u002Fprojects\u002F\u003Cproject-id>.json ）中设置  permissiongrants ，仅对当前工作区生效。 保存配置后无需重启，后续智能体在调用 chrome devtools 的任何工具时都将直接自动执行。 html pre.shiki code .svt8b, html code.shiki .svt8b{--shiki-default:#24292e;--shiki-dark:#e1e4e8}html pre.shiki code .sj4cs, html code.shiki .sj4cs{--shiki-default:#005cc5;--shiki-dark:#79b8ff}html pre.shiki code .szznc, html code.shiki .szznc{--shiki-default:#032f62;--shiki-dark:#9ecbff}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"id":98,"slug":99,"title":100,"description":101,"date":92,"category":102,"tags":103,"fullText":107},"blog\u002Fzh\u002Fblog\u002Fsix-cities-which-one-is-most-vivid.md","six-cities-which-one-is-most-vivid","六个城市，哪张最传神？","以独特视觉特征与地标、交通、市井生活、植被环境及构图视角构建的六座城市海报探索。","editor",[104,105,106],"城市","AI生成","视觉设计","六个城市，哪张最传神？ six-cities-which-one-is-most-vivid 以独特视觉特征与地标、交通、市井生活、植被环境及构图视角构建的六座城市海报探索。 editor 编辑 城市 ai生成 视觉设计 首先解读 城市名称 的独特视觉特征，并围绕以下五个元素构建场景： 一个可辨识的地标、建筑特征或天际线元素。 一种独特的本地城市移动方式。 一个微妙的日常生活瞬间。 一种本土植物、景观或环境特征。 一个自然属于这座城市的构图和视角。 整体场景结构必须因城市而异。不要反复使用相同的物体位置或视觉公式。",{"id":109,"slug":110,"title":111,"description":112,"date":113,"category":10,"tags":114,"fullText":115},"blog\u002Fzh\u002Fblog\u002Fmacos-golden-gate-27-0-beta-2-fixing-appstoreagent-at-100-cpu-with-sigstop.md","macos-golden-gate-27-0-beta-2-fixing-appstoreagent-at-100-cpu-with-sigstop","macOS Golden Gate 27.0 (Beta 2) appstoreagent 100% CPU 故障排查与 SIGSTOP 挂起解决方案","1. 故障现象 在升级至 macOS Golden Gate 27.0 Developer Beta 2 (B ...","2026-07-04",[64,65],"macos golden gate 27.0 (beta 2) appstoreagent 100% cpu 故障排查与 sigstop 挂起解决方案 macos-golden-gate-27-0-beta-2-fixing-appstoreagent-at-100-cpu-with-sigstop 1. 故障现象 在升级至 macos golden gate 27.0 developer beta 2 (b ... coder 程序员 beta macos 1. 故障现象 在升级至 macos golden gate 27.0 developer beta 2 (build: 26a5368g) 后，macbook 开始严重发热，电池电量迅速消耗。通过终端执行进程状态检索： $  ps  aux  |  grep  appstoreagent\n \u003C username >        19002 107.0  0.1 488771680  25088    ??   r    12:20am  14:55.36 \u002Fsystem\u002Flibrary\u002Fprivateframeworks\u002Fappstoredaemon.framework\u002Fsupport\u002Fappstoreagent\n 守护进程  appstoreagent  在完全没有运行 app store 客户端的情况下，持续强占单核 100% 以上 of cpu 资源，且手动强杀（kill）后会被立刻拉起，继续满载空转。 2. 日志追溯与根因定位 为锁定真实异常，我们通过系统的统一日志控制台（unified logging system）针对该进程执行特征日志抓取： $  \u002Fusr\u002Fbin\u002Flog  show  --predicate  'process == \"appstoreagent\" and eventmessage contains \"recent_launch_times\"'  --last  5m\n 日志抓取输出如下： 2026-07-04  00:34:55.462135+0800  0x7969e     error        0x0                   19002   0     appstoreagent:  (libsqlite3.dylib) [com.apple.libsqlite3:logging] no such column: active_launch_events.recent_launch_times in  \"select active_launch_events.rowid, active_launch_events.bundle_id, active_launch_events.containing_bundle_id, active_launch_events.event_source, active_launch_events.is_extension, active_launch_events.launch_end_time, active_launch_events.launch_start_time, active_launch_events.recent_launch_times, active_launch_events.timestamp, active_launch_events.payload from active_launch_events\"\n 异常分析： 异常根源 ：macos golden gate 27.0 beta 2 在内存中动态构建或迁移安全数据库 schema 时，遗漏了向  active_launch_events  物理表填充  recent_launch_times  字段的升级迁移逻辑。 死循环成因 ：由于缺少该字段，底层的 sqlite 查询不断抛出  no such column  异常。 appstoreagent  在捕获此异常后触发了 无延迟、高频的立即重试机制 ，从而陷入“查询-失败-重试”的死循环，瞬间吃满单核 cpu。 3. 为什么常规 kill 无法解决？ 在 macos 中， appstoreagent  是由系统根守护进程  launchd  管理的 user agent。 当我们对其执行  kill -9  强杀时： 进程退出，系统短暂释放 cpu。 launchd  监测到该守护服务非预期退出，立好重新将其拉起。 新拉起的  appstoreagent  实例启动，再次执行初始化数据库查询，重新触发 schema 缺失错误，cpu 再次飙升至 100%。 因此，强杀进程只会导致系统频繁进行“拉起-崩溃-再拉起”的死循环，反而会带来额外的系统进程开销与海量日志堆积。 4. 优雅的 sigstop \u002F sigcont 解决方案 由于系统只读卷受到 sip（系统完整性保护）的严格保护，普通用户无法直接修改底层数据库的 schema，我们只能通过行为干预实现临时缓解。 这里我们使用信号量控制策略： 挂起进程（process suspension） 。 发送  sigstop  信号：使进程转为  t  (stopped) 状态。此时，操作系统停止分配 cpu 周期给该进程，其  cpu 占用率瞬间降至 0% 。最关键的是， launchd  仍认为该进程处于存活（alive）状态， 不会触发重新拉起机制 。 发送  sigcont  信号：当我们需要使用 app store 时，发送该信号可立即使其恢复运行，保障应用的正常下载与更新。 我们编写了一个 python 3 守护进程脚本  guardian.py ，用于自动化这一控制逻辑： #!\u002Fusr\u002Fbin\u002Fenv python3\n import subprocess\n import time\n import os\n import sys\n import signal\n \n def get_pids(process_name):\n     \"\"\"获取指定进程名的所有 pid\"\"\"\n     try:\n         output = subprocess.check_output([\"pgrep\", \"-x\", process_name], text=true)\n         return [int(pid.strip()) for pid in output.strip().split(\"\\n\") if pid.strip()]\n     except subprocess.calledprocesserror:\n         return []\n \n def is_app_store_running():\n     \"\"\"检查 app store gui 客户端是否正在运行\"\"\"\n     return len(get_pids(\"app store\")) > 0\n \n def get_process_state(pid):\n     \"\"\"获取进程状态。返回 't' 代表已挂起，其他代表运行中\"\"\"\n     try:\n         output = subprocess.check_output([\"ps\", \"-o\", \"state\", \"-p\", str(pid)], text=true)\n         lines = output.strip().split(\"\\n\")\n         if len(lines) > 1:\n             return lines[1].strip()\n     except subprocess.calledprocesserror:\n         pass\n     return none\n \n def main():\n     print(f\"[{time.strftime('%y-%m-%d %h:%m:%s')}] appstoreagent guardian daemon started.\")\n     \n     while true:\n         try:\n             agent_pids = get_pids(\"appstoreagent\")\n             app_store_active = is_app_store_running()\n             \n             for pid in agent_pids:\n                 state = get_process_state(pid)\n                 if not state:\n                     continue\n                 \n                 # 如果 app store 打开了，并且 appstoreagent 处于挂起状态 (t) -> 恢复它\n                 if app_store_active:\n                     if 't' in state:\n                         print(f\"[{time.strftime('%y-%m-%d %h:%m:%s')}] app store is running. resuming appstoreagent (pid {pid})...\")\n                         os.kill(pid, signal.sigcont)\n                 # 如果 app store 关闭了，且 appstoreagent 没被挂起 -> 挂起它\n                 else:\n                     if 't' not in state:\n                         print(f\"[{time.strftime('%y-%m-%d %h:%m:%s')}] app store is closed. suspending appstoreagent (pid {pid}) to save cpu...\")\n                         os.kill(pid, signal.sigstop)\n                         \n         except exception as e:\n             print(f\"error in guardian loop: {e}\", file=sys.stderr)\n             \n         time.sleep(5)\n \n if __name__ == \"__main__\":\n     main()\n 5. launchd 后台静默守护部署 为了让该守护进程静默且常驻地在后台执行，我们将其包装为 macos 的 launch agent。 5.1 创建配置文件 在本地创建  com.user.appstoreagent-guardian.plist ： \u003C?xml version=\"1.0\" encoding=\"utf-8\"?>\n \u003C!doctype plist public \"-\u002F\u002Fapple\u002F\u002Fdtd plist 1.0\u002F\u002Fen\" \"http:\u002F\u002Fwww.apple.com\u002Fdtds\u002Fpropertylist-1.0.dtd\">\n \u003Cplist version=\"1.0\">\n \u003Cdict>\n     \u003Ckey>label\u003C\u002Fkey>\n     \u003Cstring>com.user.appstoreagent-guardian\u003C\u002Fstring>\n     \u003Ckey>programarguments\u003C\u002Fkey>\n     \u003Carray>\n         \u003Cstring>\u002Fusr\u002Fbin\u002Fpython3\u003C\u002Fstring>\n         \u003Cstring>-u\u003C\u002Fstring>\n         \u003Cstring>\u002Fpath\u002Fto\u002Fguardian.py\u003C\u002Fstring>\n     \u003C\u002Farray>\n     \u003Ckey>runatload\u003C\u002Fkey>\n     \u003Ctrue\u002F>\n     \u003Ckey>keepalive\u003C\u002Fkey>\n     \u003Ctrue\u002F>\n     \u003Ckey>standardoutpath\u003C\u002Fkey>\n     \u003Cstring>\u002Fpath\u002Fto\u002Fguardian.log\u003C\u002Fstring>\n     \u003Ckey>standarderrorpath\u003C\u002Fkey>\n     \u003Cstring>\u002Fpath\u002Fto\u002Fguardian.err\u003C\u002Fstring>\n \u003C\u002Fdict>\n \u003C\u002Fplist>\n [!warning] 请注意将配置文件中的  \u002Fpath\u002Fto\u002Fguardian.py  等路径修改为您在本地机器上的绝对路径。并且强烈建议配置  -u  参数，这样 python 进程的日志输出便能够无缓存地立即刷入  guardian.log  中。 5.2 引导并激活服务 给守护脚本赋予可执行权限： chmod +x \u002Fpath\u002Fto\u002Fguardian.py 将配置文件复制到用户 launch agents 目录： cp com.user.appstoreagent-guardian.plist ~\u002Flibrary\u002Flaunchagents\u002F 使用 launchctl 载入并引导该守护进程： launchctl bootstrap gui\u002F$(id -u) ~\u002Flibrary\u002Flaunchagents\u002Fcom.user.appstoreagent-guardian.plist 验证服务运行状态： launchctl print gui\u002F$(id -u)\u002Fcom.user.appstoreagent-guardian 若显示  state = running  且指定了正确的运行 pid，则代表部署成功。此时，当 app store 处于关闭状态时，您会看到  appstoreagent  在  ps aux  中的状态变为了  t  (stopped)，cpu 使用率稳稳保持在  0.0% 。而当您双击打开 app store 时，它会瞬间被唤醒提供正常服务。 5.3 服务卸载 当未来 apple 发布下一 beta 版本并修复了该 schema 迁移 bug 时，您可以通过以下命令彻底移除此临时守护进程： # 停止后台服务\n launchctl  bootout  gui\u002F $( id  -u ) \u002Fcom.user.appstoreagent-guardian\n \n # 清理配置文件\n rm  ~\u002Flibrary\u002Flaunchagents\u002Fcom.user.appstoreagent-guardian.plist\n html pre.shiki code .sscjk, html code.shiki .sscjk{--shiki-default:#6f42c1;--shiki-dark:#b392f0}html pre.shiki code .szznc, html code.shiki .szznc{--shiki-default:#032f62;--shiki-dark:#9ecbff}html pre.shiki code .szbvr, html code.shiki .szbvr{--shiki-default:#d73a49;--shiki-dark:#f97583}html pre.shiki code .svt8b, html code.shiki .svt8b{--shiki-default:#24292e;--shiki-dark:#e1e4e8}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html pre.shiki code .sj4cs, html code.shiki .sj4cs{--shiki-default:#005cc5;--shiki-dark:#79b8ff}html pre.shiki code .sj8bj, html code.shiki .sj8bj{--shiki-default:#6a737d;--shiki-dark:#6a737d}",{"id":117,"slug":118,"title":119,"description":120,"date":121,"category":10,"tags":122,"fullText":123},"blog\u002Fzh\u002Fblog\u002Fchengdu-in-3d-miniature.md","chengdu-in-3d-miniature","成都3D微缩图","","2025-12-14",[],"成都3d微缩图 chengdu-in-3d-miniature  coder 程序员  ",{"id":125,"slug":126,"title":127,"description":128,"date":129,"category":10,"tags":130,"fullText":131},"blog\u002Fzh\u002Fblog\u002Fsecurely-access-remote-synology-ssh-using-cloudflare-tunnel.md","securely-access-remote-synology-ssh-using-cloudflare-tunnel","使用 Cloudflare Tunnel 安全访问远程群晖 SSH","您是否拥有一台放在异地（例如家中或办公室）的群晖（Synology） NAS，并希望无论身在何处，都能像在本地 ...","2025-07-12",[],"使用 cloudflare tunnel 安全访问远程群晖 ssh securely-access-remote-synology-ssh-using-cloudflare-tunnel 您是否拥有一台放在异地（例如家中或办公室）的群晖（synology） nas，并希望无论身在何处，都能像在本地 ... coder 程序员  您是否拥有一台放在异地（例如家中或办公室）的群晖（synology） nas，并希望无论身在何处，都能像在本地一样通过 ssh 安全地进行管理？这里记录了如何利用 cloudflare tunnel（零信任隧道）实现这一目标。 使用 cloudflare tunnel 的优势： 无需公网 ip ：即使您的群晖处于复杂的内网环境，也无需担心公网 ip 问题。 无需开放端口 ：您无需在路由器上设置任何端口转发，极大地提升了安全性，避免了将 ssh 端口暴露在公网被恶意扫描。 高度安全 ：所有流量都通过 cloudflare 的全球网络进行加密和保护，并可享受其强大的 ddos 防护能力。 稳定且免费 ：cloudflare 为个人用户提供了慷慨的免费套餐，足以满足远程 ssh 管理的需求。 准备工作： 一台群晖 nas ：并知道其管理员账户和密码。 一个您自己的域名 ：例如  yourdomain.com ，并且您需要能够修改这个域名的 dns 设置。 第一部分：在 cloudflare 进行云端设置 在这一部分，我们将在 cloudflare 的管理后台创建一个隧道，并获取连接所需的令牌。 步骤 1.1：将您的域名添加到 cloudflare 如果您的域名还没有交由 cloudflare 管理，请先登录  cloudflare 官网 ，点击 “add a site”，按照指引将您的域名添加进来。这通常需要您在您的域名注册商处，将域名的 dns 服务器（name servers）修改为 cloudflare 指定的地址。 步骤 1.2：进入 zero trust 管理后台 在 cloudflare 主仪表盘，从左侧菜单选择  zero trust 。首次进入可能需要您选择一个免费计划并设置一个团队名称。 步骤 1.3：创建隧道 (tunnel) 在 zero trust 后台，从左侧菜单选择  access  ->  tunnels 。 点击  create a tunnel  按钮。 为您的隧道起一个容易识别的名字，例如  synology-nas ，然后点击  save tunnel 。 步骤 1.4：获取并保存连接器令牌 创建隧道后，您会看到一个“choose your environment”的页面。这里会提供在不同操作系统上安装连接器（ cloudflared ）的命令。 这是非常关键的一步！  在右侧的命令框中，您会看到一整条安装命令，类似于  cloudflared service install ey... 。您只需要复制这串命令中，跟在  install  后面的那段看起来像乱码的字符串，这就是您的隧道令牌(token)。请将这串令牌完整地复制下来，保存在一个安全的地方，我们马上会在群晖上用到它。 第二部分：在群晖 nas 上安装和配置隧道 (套件中心版) 现在，我们使用更方便的套件中心方法，在您的群晖上安装  cloudflared  软件，并让它连接到 cloudflare。 步骤 2.1：添加第三方套件源 登录您的群晖 dsm 桌面，打开  套件中心 (package center) 。 点击右上角的  设置 (settings)  按钮。 在弹出的窗口中，选择  套件来源 (package sources)  标签页。 点击  新增 (add) ，在“名称”处输入  synocommunity ，在“位置”处输入以下地址：  https:\u002F\u002Fpackages.synocommunity.com 点击  确定 (ok)  保存。 步骤 2.2：从套件中心安装 cloudflared 回到套件中心主界面，在左侧菜单选择  社群 (community) 。 在右上角的搜索框中，输入  cloudflared  进行搜索。 找到  cloudflared  套件，点击  安装套件 (install) 。 等待安装完成。这一步会自动处理好用户、权限和后台服务等问题。 步骤 2.3：配置隧道令牌 安装完成后，在套件中心找到  cloudflared ，点击 打开 (open) 。 套件的配置界面会非常简洁，通常会有一个输入框，提示您输入  tunnel token 。 将您在  步骤 1.4  中从 cloudflare 仪表盘复制的那一长串 令牌字符串 ，完整地粘贴到这个输入框中。 点击 应用 (apply)  或  保存 (save) 。套件会自动在后台启动并使用您的令牌连接到 cloudflare 的网络。 步骤 2.4：验证连接并指向 ssh 服务 回到您浏览器中的 cloudflare zero trust 后台。刷新页面，您应该能在刚才的隧道配置页面看到您的连接器状态显示为  “connected” 。如果看到了，说明您的群晖已经成功连接到云端！ 现在，我们来告诉这个隧道，当收到请求时，应该把它转发到群晖的 ssh 服务。点击  public hostnames  标签页。 点击  add a public hostname 。 填写规则：\n subdomain : 输入一个您喜欢的子域名，例如  ssh  或  nas 。 domain : 选择您的域名。 path : 留空。 service :\n type :  必须选择  ssh 。 url : 输入  localhost:22  （ 22  是群晖 ssh 服务的默认端口）。 点击  save hostname  保存。 至此，服务器端的配置已全部完成！ 第三部分：在您的电脑上配置 ssh 客户端 最后一步，我们需要配置您自己电脑上的 ssh 客户端，让它知道如何通过 cloudflare tunnel 进行连接。 步骤 3.1：在您的电脑上安装  cloudflared 您的电脑也需要安装这个工具来作为“客户端代理”。您可能会疑惑，为什么群晖上装了，电脑上还要装？这是因为它们扮演的角色不同：群晖上的  cloudflared  负责把内部服务安全地“送”到云端；而您电脑上的  cloudflared  则负责将您的 ssh 命令安全地“带”到云端。两者在云端握手，才能构成一条完整的加密通道。 官方下载地址 ： https:\u002F\u002Fdevelopers.cloudflare.com\u002Fcloudflare-one\u002Fconnections\u002Fconnect-networks\u002Fdownloads\u002F 请根据您的操作系统（windows\u002Fmacos\u002Flinux）下载并安装。例如，在 macos 上，推荐使用 homebrew： brew install cloudflared 。 步骤 3.2：修改本地 ssh 配置文件 这是让魔法发生的关键。 用文本编辑器打开您电脑的 ssh 配置文件。通常位于  ~\u002F.ssh\u002Fconfig  (macos\u002Flinux) 或  c:\\users\\您的用户名\\.ssh\\config  (windows)。如果文件或目录不存在，请手动创建。 在文件中 添加 以下配置块： # connect to synology nas via cloudflare tunnel host ssh.yourdomain.com proxycommand \u002Fopt\u002Fhomebrew\u002Fbin\u002Fcloudflared access ssh --hostname %h 请务必修改 ：\n host ssh.yourdomain.com : 将这里的  ssh.yourdomain.com  替换为您在  步骤 2.4  中设置的 完整主机名 。 \u002Fopt\u002Fhomebrew\u002Fbin\u002Fcloudflared : 将这里替换为您电脑上  cloudflared  的 实际安装路径 。您可以在终端中输入  which cloudflared  (macos\u002Flinux) 或  where.exe cloudflared  (windows) 来找到它。 第四部分：开始远程连接！ 所有配置都已完成！现在，无论您身在何处，只需打开您电脑的终端，输入我们熟悉的 ssh 命令： ssh  [您的群晖用户名]@ssh.yourdomain.com\n (请将  ssh.yourdomain.com  替换为您自己的主机名) 您会发现，系统会正常提示您输入密码，验证通过后，您就成功登录到了远方的群晖 nas！ 结语与常见问题排查 恭喜您！您已经成功搭建了一条极其安全、便捷的回家之路。 q: 连接超时或失败怎么办？  a: 首先，请回到 cloudflare zero trust 的隧道管理页面，确认您的隧道连接器状态是否为绿色的 “connected”。如果不是，请尝试在群晖套件中心重启 cloudflared 套件。如果状态正常但仍无法连接，请仔细检查您本地  .ssh\u002Fconfig  文件中的主机名和  proxycommand  路径是否完全正确。 q: ssh 连接时提示  classic tunnels have been deprecated  错误？  a: 这是因为您的 ssh 配置文件中  proxycommand  命令过时了。请确保您使用的是  cloudflared access ssh --hostname %h  而不是旧的  cloudflared tunnel ...  命令。 q: 使用  sudo  时，即使输入正确的密码也提示失败？  a: 这很可能是因为您本地电脑的键盘布局与远程服务器不一致，导致输入的特殊字符（如  @ ,  ! ,  # ）出错。请参考我们之前的讨论，使用“回显测试”或暂时修改为简单密码来解决。 html pre.shiki code .sscjk, html code.shiki .sscjk{--shiki-default:#6f42c1;--shiki-dark:#b392f0}html pre.shiki code .svt8b, html code.shiki .svt8b{--shiki-default:#24292e;--shiki-dark:#e1e4e8}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"id":133,"slug":134,"title":135,"description":136,"date":137,"category":102,"tags":138,"fullText":139},"blog\u002Fzh\u002Fblog\u002Fsource-note-ian-johnsons-foreword-to-faithful-disobedience.md","source-note-ian-johnsons-foreword-to-faithful-disobedience","翻译：张彦的前言","我初次见王怡，他领我走进一间会议室。从那里望出去，能看见成都市中心一片老旧的写字楼，成都可是中国西部最重要的一 ...","2025-04-10",[],"翻译：张彦的前言 source-note-ian-johnsons-foreword-to-faithful-disobedience 我初次见王怡，他领我走进一间会议室。从那里望出去，能看见成都市中心一片老旧的写字楼，成都可是中国西部最重要的一 ... editor 编辑  我初次见王怡，他领我走进一间会议室。从那里望出去，能看见成都市中心一片老旧的写字楼，成都可是中国西部最重要的一个大城市。那是 2011 年，他的教会当时名为秋雨之福归正教会，后来更名为秋雨圣约教会。如同许多未登记的教会一样，它坐落在一座写字楼里。这楼颇为老旧，就一部电梯还能用，嘎吱作响地把人运到十七层。我看了一眼，便决定走楼梯上去。 我说，我正在写一本关于中国宗教复兴的书。我曾去过许多中国传统基督教腹地的农村教会，比如河南省，但我感觉像这样的大型城市教会越来越重要了。我问他，是否能允许我参加教会的礼拜，再跟会友们聊聊天？ 王牧师当即同意，附带了两个条件：第一，教会内禁止拍照；第二，如果我想引用任何人的话，欢迎引用，但必须征得本人的同意。他的理由很简单：秋雨教会没有什么可隐瞒的。它是公开的，谁来都欢迎，谁想写什么也不应受到限制。所以，如果我想去他的教会，那是我的权利。如果我想写点什么，那也是我作为自由人的权利。他提出的限制，仅仅是为了尊重来聚会的人的隐私，并保持聚会的庄重。 那时，从 1980 年代中期以来，我断断续续地在中国工作。我知道，经常来他的教会可能会带给我潜在的风险。我问他关于楼下保安的问题，他们会不会向上面报告，说有个老外经常来这栋楼，还哼哧哼哧爬到十七层？ “会啊，”他说，“但外国人并未被禁止聚会。我们是一个公开的教会，没有什么可隐瞒的。来和我们一起礼拜吧。” 我们又多聊了一会儿，我觉得与秋雨教会面临的那些挑战相比，我这点思虑可能不值一提。于是，我答应了他的条件，开始定期参加教会活动，花费了数百个小时参加礼拜、神学院学习、祷告小组，还跟会友们聊天。几乎所有的会友都乐于分享他们的经历。 这对我而言，是一段特别的宗教体验的开始。我在加拿大长大，是一名圣公会（在美国称为 episcopal）基督徒，去教堂感觉很自在。但对我来说，礼拜的美主要体现在音乐，还有钦定版圣经或公祷书里莎士比亚式的语言。我遇到的大多数牧师的讲道都不太能让人信服，所以我觉得教会似乎不过是一种有意义的主日仪式，里面包含着关于如何好好生活的重要教导。 去听王怡讲道，那感觉不一样。他讲的道可不是那种匆忙塞到仪式里的几句短讲，好让大家赶紧听完去活动室喝咖啡吃甜点。他的讲道构思精巧、逻辑清晰、富有教育意义。而且，证道大多数很长。他讲上半小时是常事，大多数情况会讲长达四十五分钟。然而，你听起来并不会觉得冗长。他并未将基督教呈现为一种义务或苦差事，而是将其视为理解我们周围社会的重要途径。那时他三十八岁，六年前（2005 年）才信主，所以他自己也处在一条探索的路上——学习圣经，并将其教给我们。 这并非对王怡的颂歌。像中国许多未登记教会的牧者一样，他自学成才，熟记圣经，但有时看问题的方式有些教条。他对女性的看法（她们不能担任长老，更不用说牧师了）我也无法苟同。他与不同意见的人会发生争执，这似乎并不是合乎基督精神的解决问题的最佳方式。我想其他会友也有类似的顾虑——有些人会对他那些争论翻白眼，或者拿他的脾气开玩笑。 但对他们和我来说，参加王怡的教会是一次深刻的体验。其中一个原因在于，人们感觉自己正在参与一件完全公开透明的事情——一件他们可以参与其中并帮助管理的事情。在中国，这是一个颠覆性的想法，因为在那里，通常是由别人——往往是中国共产党——在主宰你的人生。 也有部分原因是在于他个人的魅力、口才和敏锐的头脑。他的讲道富有感染力，并不是因为辞藻华丽，而是因为他解释《圣经》的方式清晰、深刻，使其与一个中国人的日常生活息息相关。他探讨实实在在的问题，将这些问题与信仰联系起来。他完全不认为这个信仰是“西方的”或“外来的”，而是一种普世信仰，只是恰好发源于我们今天称之为“中东”的那个地方。 我写的书也包含了汉族人在中国所实践的其它信仰，所以我花了一些时间接触了佛教徒、道教徒和民间信仰的信徒。他们也是一些理想主义者，试图为他们的追随者带来一种道德体系。这种尝试对许多中国人来说至关重要，因为他们感觉自 1949 年中共建政以来，所建立的那个无道德的世界，让他们无所适从。许多其他宗教领袖也有虔诚的信众跟随，他们在他们的精神信息中找到了人生的意义和价值。 但是，王怡——以及其他未登记的新教教会——与信徒的联结最为直接。他们提供了最多的帮助和建议，组织得也最好，通常开办学校、神学院和青年团契。这就能解释为什么在新教在 2010 年代开始受到打压之前，它一度被看作是中国发展最快的宗教。 王怡对这些风险心知肚明。他知道自己随时可能被捕，但他拒绝被卷入中共所营造的那种保密文化。因此他也拒绝使用“地下教会”这个词。他的教会就是一个教会，拥有与官方教会同等的存在权利。它之所以未登记，是因为它选择不登记。我觉得这个逻辑很有说服力，在我的写作中，我更倾向于使用“未登记”（unregistered）这个词，因为它比“地下”（underground）教会（它们通常并非真的在地下）或“家庭”（house）教会（这暗示着只有十几人的小团体）更准确。实际上，这些教会租赁办公场所，开办幼儿园、神学院，甚至书店。它们就是政治学家们所称之为的公民社会——存在于政府控制之外的团体。 并非世上所有的信仰都面临这些问题。有些信仰很幸运，能存在于允许宗教自由的开放社会中。另一些则是国家认可的宗教，享受着国家支持的福利，但也承担着相应的义务。但在某种程度上，所有有信仰的人都必须决定如何与当局互动。王怡和中国其他未登记教会的领袖们深入思考了这个问题，并试图通过声明和宣言来阐明答案，本书收录的许多文献就记录了这些思考。 这些文章所反映的，可以被看作是中国特有的状况，但它们也反映出在许多国家正在发生的一场不平常的信仰迸发。在中国，信仰曾长期被禁止，但现在正处于高涨期，令当局困惑。一些信仰已被收编，特别是佛教和中国的本土宗教道教，它们享有国家支持，但也受到严格的国家管控。另一些则面临彻底的打压，比如伊斯兰教，政府对其发起了残酷的控制运动，尤其是在西部的新疆地区。还有一些，如天主教，则一直处在关于主教任命权的微妙谈判中。至于新教，政府的目标是迫使所有教会加入国家控制的组织。那些拒绝的教会，像王怡的教会一样，则面临被摧毁或至少规模被急剧压缩的命运。 中国的这些内部争斗，许多都具有全球性的影响。中国现在是世界上最大的佛教国家，并试图将其作为一种软实力工具，输出到其他佛教国家。其对伊斯兰教的压制招致了国际谴责，并导致了对在中国举办的声望卓著的活动（如 2022 年冬奥会）的部分抵制。其与梵蒂冈的谈判也受到全球约 12 亿天主教徒的密切关注。与此同时，对新教的打压也引起了广泛关注，部分原因在于社交媒体的传播。 在中国内部，这场控制宗教的运动是通过制定新法律来实施的。这些法律非但不能保护宗教自由，反而对其加以限制。这反映了中国法律体系中一个更广泛的问题。理想情况下，法律应超越统治者的意愿——即“法治”（rule of law）。但在中国和许多其他国家，法律是压迫的工具——是“法制”或曰“以法而治”（rule by law）。正是这种国家控制下的法律体系，在过去十年里将矛头对准了中国的未登记教会，并导致了王怡在 2018 年被捕。有人认为针对王怡及其教会的逼迫是个特例，辩称他过于敢言。但这种批评没有抓住重点：这个国家对所有宗教都感到不安，所有宗教最终都会成为目标——这正成为已经发生的事实。 十年前我遇到王怡时，所有这些风险，他都了然于胸。他经常写到被捕的可能性，以及面对一个政权逼迫时该如何应对。但他的结论是走一条彻底公开化的道路。他的讲道被录下来，建立了一个资料库，向任何来访者开放，无论是敬拜者还是警察。秋雨教会的人们不是偷偷摸摸从后门进来，而是穿着他们周日最好的衣服，佩戴着名牌去敬拜。他们公开地参加他们的教会并引以为豪。这是他们的教会，是这个国家管控的汪洋大海中，一个年富力强的理想主义者所带领的自由自主的孤岛。 “如此公开是有风险的，”有天早上他告诉我。“但我感觉，更大的风险是转入地下。如果我们不像自由人那样行事，我们就不会有自由的心态。作为基督徒的一个基本心态就是自由。但如果你认为自己是罪犯，你就不可能像自由人那样行事。所以我们努力走公开化的道路。” 王怡满怀真诚地走在这条路上，直到前方无法通行。如今他身陷囹圄，我想起他曾在一封写给他妻子蒋蓉的信中，谈到如果他被捕该怎么办时，他写道： “我还是传道人，你还是师母。昨天以福音为生，明天还是以福音为生。因召我们的，既是昨天的神，又是明天的神。” 我不知道 有人已经翻译过了 。不过就算是一次练习也挺好。 英文原文在  faithful disobedience: writings on church and state from a chinese house church movement  这本书中，是该书的前言。 作者张彦，英文名字是 ian johnson。他有一个很漂亮的网站  https:\u002F\u002Fian-johnson.com\u002F  ，你可以从这个网站中了解他，总之是个牛人。",{"id":141,"slug":142,"title":143,"description":144,"date":145,"category":146,"tags":147,"fullText":149},"blog\u002Fzh\u002Fblog\u002Fremembering-my-mother-in-hope.md","remembering-my-mother-in-hope","在盼望中纪念母亲","我还在开会的时候，接到弟弟的电话，说母亲走了，我没有想到这么快。春节期间，我们在成都过年，和母亲视频交流的时候 ...","2025-02-14","christian",[148],"母亲","在盼望中纪念母亲 remembering-my-mother-in-hope 我还在开会的时候，接到弟弟的电话，说母亲走了，我没有想到这么快。春节期间，我们在成都过年，和母亲视频交流的时候 ... christian 基督徒 母亲 我还在开会的时候，接到弟弟的电话，说母亲走了，我没有想到这么快。春节期间，我们在成都过年，和母亲视频交流的时候，感觉她还好好的。我匆匆订票回到了山东老家。 母亲名字叫何乃香，和我父亲是一个村。我们村子的名字很好听，西楼。不过它的名字不是来自月满西楼的婉约意境，据传乃是因为何姓村民修建的一个地主庄园的阁楼或是碉楼，所以叫何家楼，后来一部分人迁到了东边，迁过去的叫东楼，何家楼就称为西楼。到今天，楼早已经不在了，但原来楼所在位置的附近，至今仍然有个约定俗成的称呼，叫“楼底”。我母亲就出生在楼底那个范围内。 我姥姥很早就去世了，去世的时候，母亲也就只有两三岁。姥爷一个人带着母亲长大。生活当然是很艰难的。正常的人家都艰难，更何况是他们。后来她嫁给同村的我父亲，刚开始的时候日子也很难。后来我父亲开拖拉机，后来又贷款买了一辆拖拉机跑运输，生活才开始好起来。 好景不长，1987年，父亲在一次意外中丧生，那年母亲35岁。我在今天以四五十岁的年龄去设身处地想一下，那真是一段难熬的日子。大概从那时起，她的哮喘病开始严重起来。后来，我继父和母亲结婚，入赘来到了我们家，继续支撑我们的家庭。母亲先是生了一个妹妹，这个妹妹不到半岁就去世了，后来生了我弟弟。 我从初中开始住校，在家的时间很少。初中还有点假期，到了高中，一个星期也就只有半天能回一次家。我对母亲的记忆非常琐碎。小的时候经我常问她关于我出生的故事，她就跟我讲，怀我的时候，姐姐不满三岁，我是不符合计划生育政策的，所以她就逃跑，跑到她的姨家去躲着。那些细节我到现在也记不清楚了。不过这些故事，也导致我看《超生游击队》这样的节目，笑不出来。挺着肚子到处躲藏，担惊受怕，怎么会是一个喜剧呢？ 还有一些艰难的场景让人难忘。有一年，我的姨姥，也就是母亲的姨妈来看她，看到我在，给了我十块钱，我上小学，没见过这样的大钱啊，送走姨姥之后，就带着那十块去上学了，母亲追了我近两里路，把钱抢回去了。想想又心酸又好笑，母亲那时候身体还好。 母亲识字不多，对我们的教育也很简单而细碎。在村里，何姓是个大姓，她的辈分很小，导致我们出去见到个人，就是舅舅、姨、姥姥、姥爷这种级别的。母亲教育我们，要尊敬长辈，见个人就要打招呼叫人，不能因为年纪小就不称呼他们。我上初中上高中了，就念叨我好好学习；上大学了，就让我们好好交朋友，别惹呼人。我工作了，就叫我好好工作，团结同事。我结婚了，就跟我说，别打架，嘴甜儿点，对人家好。 我没有更多的回应，只有答应。我和母亲的共同的话题很少，她所知道的街坊邻居、七亲八戚的事情，我因为在外面，知之甚少。我的工作和社交圈子又没有办法和她同步。每次回去时候，基本上就是她说着，我听着。我知道她关心我，我也只能跟她说，我很好，你放心吧。 这十几年，母亲身体一直不好，哮喘导致肺部的问题，又发展为肺心症。我继父、弟弟和我姐在家把她照顾得非常好。母亲出生在1952年，按老家虚岁的算法，她过完年就是74岁了。如果没有他们含辛茹苦地照顾，她可能也不会多活这好多年。 2022年8月，母亲又一次病重，到日照的人民医院住院，按弟弟和姐姐的判断，她的状态很不好。那时候疫情方面管理很严格，我好不容易进了医院，跟她交流，她还认得我。住院期间，我太太告诉我，她怀孕了。我把这个好消息告诉了母亲。可能是个巧合，她挺过来了。出院的前一晚，我还到书奇家住了一晚，他们的小k还出生不久，他们还借车给我，让我送母亲从日照回五莲。 也就是那一次，我向她再一次传了福音，和她一起做了决志的祷告，她跟我一句句地念。 “亲爱的耶稣，我承认我有罪，我需要你，你为我在十字架，牺牲了你自己，救了我的生命。我愿意忏悔，有永远的生命，奉耶稣的名祷告，阿们。” 我还告诉她无论什么样的艰难的境况，要向耶稣祷告，说耶稣救我。我说这样将来有一天，我们会在天上见。只是我对本地的教会一点也不熟悉，母亲没有后续的牧养和跟进，也没有受洗。只有我每次回来，跟她聊一下我们的盼望和归宿。 母亲去世，我心里还在想，有没有可能请日照的教会帮助做一个基督教的葬礼。回家一看，弟弟和姐姐已经安排好了，基于强大的文化压力和对他们的敬重，我只能听从他们的意见。但是我心里知道，我有一个盼望，就是我相信母亲因为她口里承认，心里相信，就必得救。 村西边有一条岭。送完葬的第二天，天气很好。我在平房顶上拍到了落日的余晖，我看到太阳还悬在西岭上，我开车想到那里再拍一张。可是仅仅几分钟的时间，我开到那里时，太阳便已经看不见了。 小时候，我看着东边的山，西边的岭，很想知道那边是什么。我曾经走路去过东边的昆山，只不过没有爬到山顶。我也曾一路向西，最多到了满堂峪村，那里是我大姑的家，也是我在成都教会认识的曾老弟兄祖上的家。我向往外面的世界，报考大学的时候，选择了我心目中几乎最远的地方，四川成都，那时候需要坐两三天的火车才能到达。近三十年了，走过了很多路，经历过很多事。但我仍然不像我太太，对她的故乡哈尔滨充满那么多的回忆和不舍，我对一个地方没有那么多的眷恋。我只是在意一些人，人是我心里面所有的纽带。哪里有我所牵挂的人，我就向往那里。哪怕他们住在火星上，我也会觉得火星是我的家乡。 姐姐说，母亲躺着的这些年，经常透过窗子向外眺望。可能是想出去走走，也可能想看看有谁来了。我觉得特别惭愧，不能够多陪伴她。也感叹她的灵魂被限制在日渐衰残的身体中，是多么地痛苦。如今母亲睡在一个我不知道的地方，但是我知道她的名字写在了生命册上，我知道将来有一天，我必然与她相见。 以此纪念我的母亲何乃香（1952.5.14-2025.2.8）。",{"id":151,"slug":152,"title":153,"description":154,"date":155,"category":146,"tags":156,"fullText":157},"blog\u002Fzh\u002Fblog\u002Fmy-testimony-of-faith-in-christ.md","my-testimony-of-faith-in-christ","我的信主见证","我出生于山东的一个农村。在我的童年时代，直到上小学了，我们还没有通电。我印象深刻的是，夏天的夜里，人们都喜欢在 ...","2025-02-02",[],"我的信主见证 my-testimony-of-faith-in-christ 我出生于山东的一个农村。在我的童年时代，直到上小学了，我们还没有通电。我印象深刻的是，夏天的夜里，人们都喜欢在 ... christian 基督徒  我出生于山东的一个农村。在我的童年时代，直到上小学了，我们还没有通电。我印象深刻的是，夏天的夜里，人们都喜欢在麦场上乘凉。我在那里看了很多星空，也听了很多鬼故事，其中有著名的“鬼打墙”和各种聊斋的故事，导致我小时候也不敢一个人走夜路，很怕鬼。 父亲去世的故事 在农村，有一种能够“通灵”的人，一般是中老年女性，我们叫“神婆子”。很多家人得病的，出了什么事情的，都要去找她们给解决一下。1987年3月，我父亲开拖拉机出事，去世了。他去世后的第三天，有个人是我的大娘，她同时也是一个神婆，她走到我的家，一下子瘫倒在地，跟我母亲说话。她说的语言口气很像我的父亲，也跟母亲说了很多只有父亲母亲才知道的事情。大家都说是我父亲的魂附身了，我很惊恐害怕。更有一次，我亲眼看见我的一大爷被鬼附了，他身体和手臂颤抖的速度远不是一个正常所能做出来的。也让我深感害怕。 所以我很小就认识到，在我肉眼所见的世界之外，有一个我不知道灵界的存在。这些事情藏在我心里，我总是试图去寻求一个答案。 我的科学解释 当我上了大学，大学一年级有一门课，叫《现代科技》，其中讲到熵的概念。我试图用科学的概念来解释这种被鬼附的问题。我认为每个人的身体都有一种场，向外发射信号，就像一座电视塔。当电视塔突然被断电了，它发射出去的信号还在，这些信号如果被设备接收到，就会产生反应。被鬼附的情况也许就是这样，人死了，发射出去的信息被同频的人接收到，就形成了附身的效果。我对自己的答案感觉还不错，好像看起来能够自洽了。 2004年的灵异事件 但我大学毕业几年后，我就有了一次见鬼的经历。2004年秋冬有一段时间，我每天晚上躺在床上，一闭上眼睛，就能感觉到在我床脚那里，有一团黑影。我睁开眼睛，便什么也看不到。那种感觉很真实，也让我非常恐惧，我整夜睡不着觉。 我担心会不会是我的精神出问题了。于是打听了一下，听说川大哲学系有一位刚刚从法国回来，师从一位精神分析大师的老师，在川大开了一个工作室。我联系到他就去了。 这位老师的工作室开在川大的校区的老师宿舍中，里面有一张躺上去可以随意调整位置的躺椅。这个流程其实就是没有流程，全程就是让我自己讲，想说啥说啥，说完也不给我任何反馈，就让我下次再来说，说一次五十块钱。我去到第三次的时候，我是按时去的，那老师打开门，说我的时间过了。还让我再交五十块钱。我交了之后，心里觉得憋屈，就再也不去了。 我上大学的时候，宿舍和哲学系是一层楼，所以跟很多哲学系的人很熟悉。那时候很多朋友都考了研究生，我就去找他们。有一个是佛教徒，他说我这个情况啊，念《金刚经》能镇住。我就真背诵啊， 如是我闻，一时，佛在舍卫国……，与大比丘众千二百五十人俱。 但是背是背了，情况并没有改善。 查经 有一次，哲学系研究生中有一位姓王的同学，是研究基督教的。以前也有个韩国学生跟我传过福音，我没啥感觉。我和这位王同学一起吃饭，就问他，你们基督教的神能管着中国的鬼不？这位同学没有正面回答我的问题，告诉了我很多基督徒赶鬼的见证，并且告诉我，他们在川大的一个办公室有查经班，每周都有，邀请我去。我就去了，开始查经，通过查经，我才知道真的有一位上帝，也只有一位上帝。那时候，正好赶上基甸在《新语丝》上与方舟子辩论，我除了每周去查经之外，每天都看他们的辩论。也从科学的角度看进化论的不可靠和上帝存在的证据，也瓦解了我心目中所谓的“科学观”。其中有个例子我到现在还记忆犹新： 我们说照相机是根据人的眼睛的成像原理制造的。然而我们认为一个照相机必须得有人设计和创造，但人的眼睛比照相机更加精妙，却不用创造，自然界自己就能形成。这很不科学。 不多久，我晚上就看不见那团东西了，我的见鬼问题好了。 戒烟 我从高中毕业开始抽烟，抽得很厉害，大概两天三包烟的量吧。我以前谈恋爱的时候，女朋友也希望我戒烟，我自己也想戒。但立誓戒过八九次，每次都相当地艰难，最多的时候戒过一个月。有一次查经完了，我到楼下就点了一支烟。有一位弟兄从后面看见我抽烟，就说，“叶弟兄，身体是圣灵的殿，你怎么能在殿里烧火呢？”我心里很惭愧，想在受洗前能够戒烟，就请大家为我祷告。 有一天，我在办公室里，看一个叫做基督徒生活网的网站（这个网站应该现在还有， cclw.net ）。里面讲到有一个基督徒信主之后，想戒酒的故事。他就把他所有收藏的酒全部倒掉打烂了。这时候，我好像听到有一种声音，又好像不是声音，而是一种意识，一个呼声或者是命令，说，“把你桌子上的烟丢掉垃圾桶里去”。我就照做了。 这是非常奇妙的体验，从那天那一刻开始的很长一段时间，我闻到烟味就觉得很难受，也一点都不想抽。现在过了20年了，我偶尔为了陪别人，会抽几支烟，再也没有烟瘾了。上次陈阿姨在群里说看到有人抽烟的情况，我相信那是出于爱的劝告。但我一般不劝人戒烟，因为我知道这个真的很难，而且我这是我蒙上帝的恩典，祂用神迹开挂的方式帮助我戒的烟，我不好意思去要求别人戒。求主帮助被烟瘾捆绑的弟兄们，愿主亲自帮助。 受洗 2005-03-27 2005年3月27日，是复活节。我在三道堰的府河上游的河里受洗，成为正式的基督徒。到今年三月，就整整二十年了。近二十年中，我经历过很多的事情，有些事情需要理性去理解，有些事情，理性无法解释，需要顺服；也有些事情，会让我怀疑上帝。但借着信主的经历和主赐的奇妙神迹，这些恩典给我确信，让我在信与不信之间不再摇摆。 我的见证不太理性，看起来也很不“秋雨”。但上帝拣选人的方式奇妙，给每个人的路径都不同。给我的路径大概是——在科学和迷信之间，怕鬼引导我成为耶稣的门徒。感谢上帝的拣选，荣耀归给祂，直到永远。",{"id":159,"slug":160,"title":161,"description":162,"date":163,"category":164,"tags":165,"fullText":167},"blog\u002Fzh\u002Fblog\u002Fmy-son-ye-jiale.md","my-son-ye-jiale","我的儿子叶嘉乐","​3月15日，是我儿子叶嘉乐的生日。如果他尚在人世，已经七周岁了。 怀胎 2015年7月我太太被检查出怀孕。2 ...","2023-03-31","father",[166],"儿子","我的儿子叶嘉乐 my-son-ye-jiale ​3月15日，是我儿子叶嘉乐的生日。如果他尚在人世，已经七周岁了。 怀胎 2015年7月我太太被检查出怀孕。2 ... father 父亲 儿子 ​3月15日，是我儿子叶嘉乐的生日。如果他尚在人世，已经七周岁了。 怀胎 2015年7月我太太被检查出怀孕。2016年初的某天上午，我正在上班的时候，接到了太太打来的电话，说医院在胎儿的检查中，发现有心脏主动脉瓣狭窄的问题，当时已经差不多怀胎7个月了。我们后来也去了北京的安贞医院，确诊了这个问题。 当时我太太还有些犹豫，这个孩子到底要不要。我鼓励她，说孩子的主权在于上帝而不是我们。上帝给的，上帝会负责。如果我们不要他，这罪要归于我们。所以我们两个人彼此鼓励和搀扶，迎接孩子出生。我给他取名叫叶嘉乐，意思是愿他因为喜乐被上帝嘉奖。 出生 他刚刚出生后两个小时，我们生产的医院没有icu，就要强行转院，我们咨询了一些儿科专家，觉得在新生儿这个阶段，主动脉瓣狭窄也无法干预治疗，但医院怕承担责任，不同意继续留下本院。在教会李相学牧师和李晓东老师的陪伴下，我抱着叶嘉乐离开了医院。快跑了半个北京城，我们最终决定，带他回家。这是无奈的决定，也是对孩子最好的决定，因为孩子在刚出生的时候，做无意义的治疗，而和父母隔绝，有些残忍。 治疗 中间他经过了一段较长的黄疸。后来去了北大医院住院，医生下了病危通知书。有一天，办住院的时候，我推他无意间到了一个天主教堂，与他合影，还进去祷告了。过了一段时间，他奇迹般地好转了。我们很高兴医生的判断是错的。 欢乐 百日的时候，我们策划了一次拍照diy。 夏天，我们全家回了姥爷姥姥家，一起游了松花江，去过索菲亚教堂。 秋天，和教会的弟兄姊妹一起去烧烤秋游。 叶嘉乐和我经常有很多互动。 我现在才知道他有一点“斗鸡眼”，可是有什么呢？他看我的眼睛使我的心融化。 转眼到了春天，3月15日过生日那天，我们带他去买了小汽车，游玩了朝阳公园，一起吃了生日餐。 生病 终于，一周岁生日过后不久，因为一次小的感冒，他呼吸困难，住进了儿童医院。病情恶化的程度远远超出我们的想像。我们曾经幻想几岁给他动手术，但这一次，医生很快给了病危通知。 3月29日，医生说必须让他进儿童icu病房，我们看到他离开我们时撕心裂肺的哭叫，心都碎了。但这还不是最绝望的时候。 绝望 过了不到半小时，icu的医生打电话给我们约谈。医生说，现在所有的治疗都没有意义了，希望我们把他带回家。甚至说，给我们备几袋氧气在路上使用。如果在路上停止呼吸，可以找附近的医院开证明。我们很感恩医生做出这样的决定，我不想让他孤单地在医院走完人生的道路。 这是我走过的最漫长的路。我前面开着车，太太在后面抱着他。我们哭着喊他的名字，让他保持一点清醒。同时打电话通知所有的亲人和教会的弟兄姊妹，来和他道别。 那天晚上，亲人都到齐了。我们请牧师为他施了洗礼。离别的时刻终于到了。 离别 2017年3月30日，乐乐在家中停止了呼吸，息了他的劳苦。那一天，上帝给了我三个印记，给我们安慰和盼望。 第一，在乐乐弥留之际，我想起有两次他晚上经常不睡而哭闹，我因为劳累对他态度不好，打了他的屁股。我跟他说，爸爸态度不好，打了你，对不起，请你原谅爸爸。他当时的呼吸急促而沉重，但却发出一声响亮的“嗯”。我的孩子叶嘉乐真的饶恕了我。 第二，他停止呼吸之后，过了一会儿，我去房间里看他，他的脸角上扬，带着笑容。 第三，那一天，上帝借着微读圣经向我们说话，成为我们莫大的安慰： 我实在告诉你们，你们若不回转，变成小孩子的样式，断不得进天国。所以，凡自己谦卑像这小孩子的，他在天国里就是最大的。”(马太福音 18:3-4) 送别 2017年4月1日，我们在北京的教会会堂，为叶嘉乐做了追思礼拜。很多人一起为他送行。 有人问我们，后悔生下他吗？没有，没有后悔。我们特别感恩叶嘉乐带给我们这一年零15天的喜乐。生命的长短，一天，一年，或者一百年，在永恒面前，都是一瞬间。圣经说，“其实明天如何，你们还不知道。你们的生命是什么呢？你们原来是一片云雾，出现少时就不见了。” 世界终将会遗忘叶嘉乐这个名字，但是他的名字被记在生命册上了。为人父母，一生的努力，不就是把孩子带到上帝的面前，使他有永生的生命吗？ 在2016年的圣诞节，我们给他写了一张贺卡，我们盼望他为荣耀主的名好好活着。 如今他不在世上，但是，愿上帝的荣耀在他身上。 来成都 我们想他吗？想，真想，每天都想。难过吗？当然难过，有时候我们看着他的照片和视频就流泪。喜乐吗？喜乐，想到他安稳在祂的手中，知道他是好得无比。 我们从北京来到成都之后，叶嘉乐的经历也帮助了很多失去孩子的家庭，比如失去子秘的杨彪晓岚家，和失去李卓谦弟兄的忠哥海玲姐家。 在李卓谦弟兄的追思礼拜上，我写下这样的祷词： ……我的儿子叶嘉乐是我的帮助者。从前我的肉身沉重，我贪恋地上的事，不爱慕上帝的国。我儿子离开以后，每当我想起他，我就觉得自己应该多多服侍你，我盼望通过我的服侍使你的国速速到来。  对于世界来说，人一生最大的成功就是活几十年最多百年。但对于一个在基督里的人，他一生最大的成功就是能去天国并且带人去天国。如今，这两个在耶稣里的孩子做到了。……靠着耶稣，终有一天，我们将与李卓谦弟兄一同在天国里相见，我盼望着在那边，我们还要一同唱诗赞美做工服侍。愿荣耀归于天父，直到永永远远。奉主耶稣的名祷告。 后记 2023年3月30日，在叶嘉乐离世整整六年后，上帝的恩典使我们在这一天生下弟弟，我们给他起名叫叶嘉信——盼望他能因为信心得到上帝的嘉奖。上帝为了不让我们以为2023年3月30日仅仅是一个巧合，又将弟弟的体重设计为3330克，将弟弟的出生时间设为9点整。 但你就是你，没有人可以代替你。我们不会忘记你的名字——叶嘉乐。",{"id":169,"slug":170,"title":171,"description":172,"date":173,"category":174,"tags":175,"fullText":176},"blog\u002Fzh\u002Fblog\u002Fmy-personal-history-with-television-media.md","my-personal-history-with-television-media","我的电视媒体变迁史","来到成都之后，才发现好多弟兄姊妹的家庭，为了孩子的教育，家里没有安装电视，这给了我很大的震撼。我则不然，自从上 ...","2022-10-04","technician",[],"我的电视媒体变迁史 my-personal-history-with-television-media 来到成都之后，才发现好多弟兄姊妹的家庭，为了孩子的教育，家里没有安装电视，这给了我很大的震撼。我则不然，自从上 ... technician 技师  来到成都之后，才发现好多弟兄姊妹的家庭，为了孩子的教育，家里没有安装电视，这给了我很大的震撼。我则不然，自从上小学后，看过《西游记》《聪明的一休》等电视片之后，就喜欢看电视。 黑白电视 我记得，村里总共有两台还是三台电视，看《西游记》的时候，一个院子里站满了几十上百人。其实没有扩音设备，声音听不太清楚，14寸的小屏幕，隔着十几米，也没法看细节，喜欢的就是氛围，心里渴望的，是更大的世界。 电影《你好李焕英》中的看电视的场景 彩电 上世纪八十年代末，继父带来一台四川长虹厂生产的14寸彩色电视机，终于结束了去别人家看电视的历史。这种电视是地面电视，用无线传输，需要室内天线或室外天线。这个电视有8个换台的按钮，按钮右侧是能打开的，里面还可以对信号和色彩进行细调。我上初中就住校了，每周回来一两次，走的时候有点舍不得电视，经常看过下午山东台的“广告文艺”之后再返校。 卫星电视 上高中没看过电视，大学也尽看录像和电影了。2005年我去北京工作，开始迷上卫星电视。当时我住在北三环蓟门桥边上的明光北里小区，有个朝南的阳台，对面楼下就是中国政法大学的本部。在一个不满两平米的阳台上，我开始自己的烧星历史。 用电风扇架撑起来的天线，最高点为高频头 卫星接收机是dm500s，前面还用过一台机器是什么型号我忘记了。卫星电视很多不是免费的，需要收视卡。收视卡是很贵的，一个卫星上的收视卡大概要一两千块钱吧。在我盗版国，他们想出了一个方案。就是只买一张正版卡，放在一个服务器里，然后所有的接收机上联网，去读取那个正版卡上的账号信息。 用这个小小的dish天线，大概可以收几颗星。但我主要是接收138度上的亚太5c卫星上的节目。在这颗卫星上，集合了bbc\u002Fcnn\u002Fhbo\u002F中天\u002F东森\u002F凤凰卫视\u002F国家地理，还有cctv的几个频道。经常收看的是台湾的一个福音电视台——好消息goodtv。 有一个基督徒的访谈节目《真情部落格》是我经常看的，是让一些基督徒来讲他们的见证。有一期采访一个叫江锡铭的节目，叫《沙漠开江河》。他现场演奏了一诗自己创作的诗歌（视频45分11秒开始），我到现在都记得： 不再随波逐流 从此跟主而走 不再随波逐流 我今回头 求主爱我 不再随波逐流 \n从前迷途 不知回头 耶稣为我代求 从此从此 浪子回头 耶稣仍然爱我 李晶玉主持的《真情部落格》 这个电视台还放很多证道的节目，比如说“约尔欧斯汀”（ https:\u002F\u002Fwww.joelosteen.com\u002F ）的证道，后来才体会到这才是标准的成功神学的证道。 那为什么不用youtube？youtube2005年才成立，节目源也没多少啊。 机顶盒 2012年，开始流行一个叫“麦格tv”的iptv盒子。我从1代用到了3代。它大概的原理是：在香港、台湾或大陆某地对一些卫星电视或有线电视的信号源进行采集，然后通过视频流的方式转播。大概能收一两百个电视台，包括欧美、港台和中国大陆的各大卫视。所以，这个盒子当时不仅在中国大陆，包括全世界的华人电视爱好者都在使用。 调试机器中，白色的盒子为麦格第一代 节目源很多，右下为第二代 2014年下半年，第三代产品h3d型号推出后，不到一年时间，香港和大陆两地开始对这种盗版方式进行打击。服务器被关闭。 有时候不是很稳定 2020年底，有一天我突然接到了原来加的一个麦格代理的qq消息，问我还记不记得他。那几天他刚刚出狱，5年与世隔绝，他怕世界已经把他忘记了。 网络电视 2014年android tv才开始发行，可以说这是一套操作系统，我买了几个基于androidtv的小米盒子，印象最深的是小米盒子3增强版。它可以用root的方式安装谷歌框架，从而安装youtube观看。但后来由于小米公司对用户安装的软件进行审查并且偷偷删除，弃用了。 mibox s 国际版是小米公司推出的一款针对国外市场的电视盒子，除了传统收看youtube之外，有netflix的认证，可以收看netflix。记得第一次把netflix安装好之后，兴奋了好一阵子。 2019年，第一次使用netflix 今年，在给一个朋友推荐电视盒子的时候，发现mibox s 已经不太流行了。谷歌在电视棒chromecast上内置了google tv，推出了chromecast with google tv。售价39.99美元，国内的价格，不足400人民币。 chromecast除了外表漂亮以外，界面也非常美观。如果你能有一个美国的ip地址，可以看到这个有很多选项的界面。如果是非美国的ip，则是一个非常简洁的界面。 使用美国ip的界面 并且，美国的用户，会内置pluto tv里的电视台。大概有上百个电视台可以播放。 pluto tv提供的免费直播电视台 作为漫威和国家地理的粉丝，我订阅了disney+，有五个部分的电视节目可以收看：disney迪斯尼\u002Fpixar皮克斯\u002Fmarvel漫威\u002Fstar wars星战\u002F国家地理（根据ip可能会有变化）。disney+是值得订阅的，虽然它对ip的要求是非常严苛的。 disney+ 的界面 结语 电视媒体的重要作用是传递信息，获取信息是人的基本权利。 我不认为谁坐在高位上都一样。如果毛再活四十年，我应该看不到除了中国以外的电视节目，跟在朝鲜的状态差不多。 改革开放给了我机会，让我更多知道这个世界。",{"id":178,"slug":179,"title":180,"description":181,"date":182,"category":146,"tags":183,"fullText":185},"blog\u002Fzh\u002Fblog\u002Fformat-specification-for-chinese-sermon-documents-first-draft.md","format-specification-for-chinese-sermon-documents-first-draft","中文证道文档整理格式规范（初稿）","前些年，我曾经做过几篇证道的整理。过程中我发现，在网络上没有一篇完整的中文证道录音整理方面的规范文本，我自己尝 ...","2022-09-08",[184],"编辑","中文证道文档整理格式规范（初稿） format-specification-for-chinese-sermon-documents-first-draft 前些年，我曾经做过几篇证道的整理。过程中我发现，在网络上没有一篇完整的中文证道录音整理方面的规范文本，我自己尝 ... christian 基督徒 编辑 前些年，我曾经做过几篇证道的整理。过程中我发现，在网络上没有一篇完整的中文证道录音整理方面的规范文本，我自己尝试做了一些规范，与各位弟兄姊妹一起探讨。 标题与文章结构 本部分规范以使用markdwon为例说明，word文档同理。 层级 标题分为四级 - 一级标题：文章的标题 三级标题：文章主要部分的大标题 四级标题：三级标题下面一级的小标题 五级标题：四级标题下面某一方面的小标题 以下是示例 # 渴望完美的带领与顺服 引言 超然带领与顺服 通常带领与顺服 1、上帝子民的合一与前行（10.1-7） 1）子民的合一 2）子民的前行 2、上帝子民的争战与敬拜 （10:8-10） 结论 上面示例的渲染结果如下： 渴望完美的带领与顺服 引言 超然带领与顺服 通常带领与顺服 1、上帝子民的合一与前行（10.1-7） 1）子民的合一 2）子民的前行 2、上帝子民的争战与敬拜 （10:8-10） 结论 为什么不推荐使用二级标题开始？ 在各个编辑器默认的字号渲染中，一级标题字号最大，以下逐级标题字号依次变小。二号标题使用在正文中，如果文章很长，如较长的论文或者书籍是比较合适的。 但在证道文章中，字数一般不超过两万字。文章的主体结构一般也不超过三级，这样正文以二级标题开始，字号过大。故推荐自三号标题开始。 原则 在正文中使用标题要避免孤立，即同级标题不能只有一个。 示例：在下面的文章结构中， 二级标题 a 只包含一个 三级标题 ，完全可以省略 三级标题 a 。 ## 二级标题 a 三级标题 a 二级标题 b 下级标题不重复上一级标题的名字 示例：下面的文章结构，二级标题与下属的三级标题同名，建议避免。 ## 概述 概述 尽量避免下面的情形 下级标题不必重复上级标题 ## 概述 概述-第一点 概述-第二点 标点符号 原则 （1）中文语句的标点符号，均应该采取全角符号，这样可以与全角文字保持视觉的一致。 （2）如果整句为英文，则该句使用英文\u002F半角标点。 （3）句号、问号、叹号、逗号、顿号、分号和冒号不得出现在一行之首。除非特意在句首前面放置标点符号，否则在现代浏览器和编辑的渲染中已经自动规避了这个问题。 句号 （1）中文语句的结尾处应该用全角句号（ 。 ）。 （2）句子末尾用括号加注时，句号应在括号之外。 错误：再到1949年，中国约有80万名新教信徒，人数远远少于大约300万的天主教徒（当时中国人口是5.4亿人。） 正确：再到1949年，中国约有80万名新教信徒，人数远远少于大约300万的天主教徒（当时中国人口是5.4亿人）。 逗号 （1）逗号（ ， ）表示句子内部的一般性停顿。 （2）注意避免“一逗到底”，即整个段落除了结尾，全部停顿都使用逗号。 顿号 （1）中文句子内部的并列词，应该用全角顿号( 、 ) 分隔，而不用逗号，即使并列词是英语也是如此。 错误：所以约瑟站在他们的面前，拥有赦免拯救他们，或者是来审判报复他们的权柄，能力和地位。 正确：所以约瑟站在他们的面前，拥有赦免拯救他们，或者是来审判报复他们的权柄、能力和地位。 （2）英文句子中，并列词语之间使用半角逗号（ , ）分隔。 （3）中文句子内部的并列词，最后一个尽量使用（ 和 ）来连接，使句子读起来更加连贯，下面两个句子都可以，第二个更优。 不推荐：所以约瑟站在他们的面前，拥有赦免拯救他们，或者是来审判报复他们的权柄、能力、地位。 推荐：所以约瑟站在他们的面前，拥有赦免拯救他们，或者是来审判报复他们的权柄、能力和地位。 分号 （1）分号（ ； ）表示复句内部并列分句之间的停顿。 引号 （1）引用时，应该使用全角双引号（ “ ” ），注意前后双引号不同。 例句：你不要小看这个“一”，自从亚当以来，亚当的家庭合一首先就被破坏了，然后到了后面，人越来越分散。。 （2）引号里面还要用引号时，外面一层用双引号，里面一层用单引号（ ‘ ’ ），注意前后单引号不同。 （3）引用之语未独立，标点符号引号外。 引用之语能独立，标点符号引号里。 括号 （1）补充说明时，使用全角圆括号（ （） ），括号前后不加空格。 例句：### 超然带领与顺服（9:15-23）。 冒号 （1）全角冒号（ ： ）常用在需要解释的词语后边，引出解释和说明。 例句：请确认以下几项内容：时间、地点、活动名称和来宾数量。 （2）表示时间时，应使用半角冒号（ : ）。 例句：早上 8:00 （3）表示圣经经文的章节间隔，应使用半角冒号（ : ）。 正确：创世记1:1、彼得前书2:1 错误：创世记1：1、彼得前书2：1 省略号 （1）在证道中，省略号无法读出，一般讲道人会使用“等等”等词语来表示。 （2）省略号（ …… ）表示语句未完、或者语气的不连续、经文或文章引用时中间略去的部分。 （3）省略号占两个汉字空间、包含六个省略点，不要使用 。。。 或 ... 等非标准形式。 例句：“看哪，弟兄和睦同居，是何等的善，何等的美……因为在那里有耶和华所命定的福，就是永远的生命”。 感叹号 （1）整体证道文章的整理，应该尽量避免使用感叹号（ ！ ）。 （2）绝对不允许多个感叹号连用，比如 ！！ 和 !!! 。 （3）祷告部分中的“阿们”，后面一般加“！”，也可以加“。” 破折号 （1）破折号 ———— 一般用于进一步解释。 （2）破折号应占两个汉字的位置。如果破折号本身只占一个汉字的位置，那么前后应该留出一个半角空格。 例句：这段时间有五十个左右的同工————教会的不同的同工，学堂的不同的老师————他们每个星期六上午有三四个小时参加同工的系统培训 连接号 （1）连接号用于连接两个类似的词。 （2）以下场合应该使用直线连接号（ - ），占一个半角字符的位置。 圣经经文的表示章节的范围 表示年份的范围。 例：创世记2章1-2节、创2:1-2。 例：2005-2008年 （3）数值范围（例如数字）应该使用波浪连接号（ ～ ），占一个全角字符的位置。 例句：约有2000人～3000人决志信主。 注意，波浪连接号前后两个值都应该加上单位。 （4）连接号也可以用汉字“至”代替。 例句：2005年至2008年 –to be continued",{"id":187,"slug":188,"title":189,"description":190,"date":191,"category":146,"tags":192,"fullText":195},"blog\u002Fzh\u002Fblog\u002Fhow-a-church-organize-a-wedding.md","how-a-church-organize-a-wedding","教会如何组织一场婚礼","结婚是一场礼拜 一对新人是一场婚礼的主角，这么讲听起来没什么错。但是对一个基督徒来讲，人生的首要目的是荣耀上帝 ...","2021-08-22",[193,194],"婚礼","服侍","教会如何组织一场婚礼 how-a-church-organize-a-wedding 结婚是一场礼拜 一对新人是一场婚礼的主角，这么讲听起来没什么错。但是对一个基督徒来讲，人生的首要目的是荣耀上帝 ... christian 基督徒 婚礼 服侍 结婚是一场礼拜 一对新人是一场婚礼的主角，这么讲听起来没什么错。但是对一个基督徒来讲，人生的首要目的是荣耀上帝，那更何况是你们的婚礼呢？本质上讲，婚礼是借着一对新人的结合对上帝的敬拜。所以我们称之为“结婚礼拜”，简称“婚礼”。 婚前辅导 世俗世界认为婚姻是不必学习的，或者至少是可以自学成才的。但大部分基督徒和所在的教会认为，婚姻需要以圣经为基础的教导。以我所在的教会为例，一般需要经过八次课程，历时3-6个月的婚前辅导并顺利完成后才可以举行婚礼 场地 会堂是婚礼的首选场地。但对于一个没有会堂或是失去会堂的教会中的新人来说，一场婚礼最首先需要确定的，就是场地。确定场地需要考虑如下因素： 观礼人数。预估双方亲属、朋友和教会会友前来观礼的数量，从而决定座席足够。 预算。在有会堂的情况下，场地的费用是不需要考虑的。但无会堂的情况，场地需要由新人来支付，需要由双方根据实际情况共同商定。 场地风格。每个人所喜好的婚礼风格均不同，在预算适当的情况下，双方可以选择适合自己的风格，比如室内、户外；中心区或郊区的不同的场地风格。 布置风格。 下面是一些可供参考的场地： 不同星级的酒店宴会厅 公园户外 小型博物馆 演出场地 大型商场中的展厅 专业展陈场馆 时间 在中国各地世俗的婚礼和婚宴中，婚礼时间的选择上，有不同的习俗和时段。我们的教会一般在下午举行婚礼，一般建议在14:00至15:00的时间段内开始，在16:30前结束。具体时间可以由双方根据实际情况拟定。在下午举行婚礼有如下一些好处： 不必起床太早，包括新人、服事参与者和观礼的人； 教会的婚礼不设宴席；在上午举行时，可能的延迟会耽误大家用餐； 场地的布置需要大量鲜花，如果在上午举行，则需要前一天晚上全部布置好，鲜花可能会不新鲜。 人员 在确实好场地和时间后，需要新人确定的邀请人选，包括： 婚礼流程 查看notion文字版 faq 什么时间准备婚礼合适？ 如果你们已经开始婚辅，就可以着手准备一些准备工作了。 有哪些费用是由新人出的？ 在没有会堂的情况下，所有涉及婚礼的花费都需要由新人来支付，包括但不限于：场地费用、布置费用、所需物料、茶点等；如果教会仍有可用的会堂，则没有场地费用。 教会的服侍只限于人力，如果有费用垫付，则需要由新人同意。 为什么会友不送礼，新人不请客？ 婚礼的首要目的是见证上帝的荣耀。会友参加婚礼，是对新人的祝福和对上帝的敬拜。新人获得大家的祝福是最重要的美事。 现实角度看，在一个较大的教会，如果一年有多场婚礼，送礼会给会友造成经济负担，参加婚礼也就失去了祝福的意义。 如果既是会友，又是新人的好友，送礼则是一个私交的范畴，应在婚礼前(后)进行。但如果新人在教会中担任一些职份，则必须要遵守所在教会中的相关收受赠礼的规定。 如果有朋友在婚礼时送礼品和礼金怎么办？ 婚礼在很多未信主的亲戚和朋友参加时，可能会涉及送礼的情况，新人应指定1-2名亲友来记录和保管收到的礼金和礼品。",{"id":197,"slug":198,"title":199,"description":200,"date":201,"category":146,"tags":202,"fullText":204},"blog\u002Fzh\u002Fblog\u002Fremembering-pastor-and-elder.md","remembering-pastor-and-elder","辛丑年忆牧长文","江信楼外，锦水澹澹，戊戌年冬别后，近三载矣。 丁酉年秋，舍下自帝都迁蜀，为生计往返帝都锦城之间，几失入学。翌年 ...","2021-06-01",[203],"信仰","辛丑年忆牧长文 remembering-pastor-and-elder 江信楼外，锦水澹澹，戊戌年冬别后，近三载矣。 丁酉年秋，舍下自帝都迁蜀，为生计往返帝都锦城之间，几失入学。翌年 ... christian 基督徒 信仰 江信楼外，锦水澹澹，戊戌年冬别后，近三载矣。 丁酉年秋，舍下自帝都迁蜀，为生计往返帝都锦城之间，几失入学。翌年六月，终转至圣约堂。服事日久，于诸弟兄姊妹相见如故。然牧者长老，我则趋避之。盖恐其若得主恩赐，识破我心之罪恶虚伪，岂不祸哉？ 九月，方知新堂既成。至六楼，堂中皆狼藉。长老覃兄掌堂会诸事，穿梭其中。上前请缨，曰：“装电视”。长老身形精致，面若冠玉，唇红齿白，碌碌中亦不忘露齿一笑，与之并肩共事至丑时而归。是为相识。 牧者面圆，善诗文，其笑可掬。证道如高山流水，时而涓涓，时而汩汩。初识声名于网络，入蜀方得见肉身。听道一年有余，每每坐前排，乃恐后排嘈杂困顿，扰我心魂。会后常与之相视而笑，执手问安。至戊戌教案始发，对谈竟无一句。唯顾其影，闻其所传恩主十架以纪念之。呜呼，尝叹之于道中诸弟兄，示爱宜趁早。 噫！古人云：“命之所存，天实为之”，如保罗之于罗马，约翰之于拔摩，焉可从已意？四载试我兄长，九年炼我牧人，主所志必成，我何奈之？夜中思我懦于斗米，苟且偷生，真小人也。胸憶难平，何所盼耳！然经上云： “我望伊何？实惟主兮。援我於罪、勿使恶人侮予兮。” 上主怜其子民，虽四散流离，然于基督中，合成一身，互相为体。非以高墙为隔，不以山海为远。举手向天，此唱彼和，曰：“圣哉圣哉，荣光耀奕，顾其饮食，观其卧立，护其父母，庇其妻子。思之涕泪，求神拭之，耶和华兮，俯听我祈。” 是以为记。窄门下晚生叶某人，六月。 译文： 江信大厦旁边，锦江上微波荡漾。2018年冬天一别后，快三年了。 2017年秋天，我从北京迁到成都生活，工作则需要往返北京和成都，耽误了几次转会学习。直到第二年6月，才转会到秋雨圣约教会。服事的时间长了，跟弟兄姊妹都很熟悉，像认识了很多年一样。可是对于牧师和长老，我一般都躲着走。我害怕他们万一有什么恩赐，能看透我这个罪人的心思，岂不是很麻烦？ 到了9月，我们才知道新堂已经准备好了。我去六楼，看到新堂里一片狼藉。覃长老是管理会堂的，在里面穿梭忙碌。我去请他派点事干，他说：“你装电视吧”。覃长老个子不高，身材不错，皮肤白皙，容貌佳美，忙碌中脸上也总是带着笑容。那天我跟他一起工作到后半夜，算是我们第一次认识。 牧师脸圆圆的，诗和文章写得好，又平易近人很喜乐。他的证道像山川的流水，时而涓涓细流，有时又激扬澎湃。我最初从网络上知道他，到了成都才见到他的样子。教会里听道一年多，每次都是坐前排，因为怕后面有吵嚷声，影响听道。聚会完常常与他相视一笑，握握手说声平安。一直到一二九教案，也没有跟他正正经经说过什么话。后只有看他的照片视频，听他所传讲耶稣基督救恩的讲道来纪念他了。哎！我常常跟弟兄们说，要是你爱谁，一定要早说出来啊。 唉。古人说：“你生命中所遇到的，实际上是上天的安排。”就如保罗被带到罗马城，约翰被关在拔摩岛，哪里能自己作主呢？把我兄长关四年，把我牧师关九年，为要试炼他们，主所做的事必成就，我能怎么办呢？睡不着的时候想起自己为了生计胆小怯懦，凑合这么活着，真是个小人啊。一时感慨万千，有什么盼望呢？但圣经上说：“主啊，如今我等什么呢？我的指望在乎你！求你救我脱离一切的过犯，不要使我受愚顽人的羞辱。” 上帝怜悯祂的子民，虽然我们被分散到各地，但是耶稣基督里，成为一体。在主里的联络，高墙不能阻挡，山海不能隔断。愿主里的弟兄姊妹常常举手祷告，说：“主耶和华圣哉！你的荣耀充满全地！求你看顾他们的饮食起居，保护他们的父母妻儿。我们想念他们所流的泪水，求你为我们擦干。主耶和华啊，求你侧耳听我的祷告。” 这就是我想说的。同在主里的弟兄叶某某写于2021年6月。",{"id":169,"title":171,"body":206,"canonical":120,"category":174,"date":173,"description":172,"extension":425,"image":426,"meta":427,"navigation":428,"path":429,"seo":430,"slug":170,"status":431,"stem":432,"tags":433,"translationSlug":170,"__hash__":434},{"type":207,"value":208,"toc":415},"minimark",[209,213,217,220,226,229,232,235,240,243,246,251,254,257,262,265,268,281,284,297,300,303,306,311,314,319,322,325,330,333,336,341,344,347,350,355,358,361,366,369,374,377,380,385,388,391,396,399,402],[210,211,212],"p",{},"来到成都之后，才发现好多弟兄姊妹的家庭，为了孩子的教育，家里没有安装电视，这给了我很大的震撼。我则不然，自从上小学后，看过《西游记》《聪明的一休》等电视片之后，就喜欢看电视。",[214,215,216],"h3",{"id":216},"黑白电视",[210,218,219],{},"我记得，村里总共有两台还是三台电视，看《西游记》的时候，一个院子里站满了几十上百人。其实没有扩音设备，声音听不太清楚，14寸的小屏幕，隔着十几米，也没法看细节，喜欢的就是氛围，心里渴望的，是更大的世界。",[210,221,222],{},[223,224],"img",{"alt":120,"src":225},"\u002Fimages\u002Fposts\u002F2022\u002F10\u002Flihuanying_tv-1024x466.jpg",[210,227,228],{},"电影《你好李焕英》中的看电视的场景",[214,230,231],{"id":231},"彩电",[210,233,234],{},"上世纪八十年代末，继父带来一台四川长虹厂生产的14寸彩色电视机，终于结束了去别人家看电视的历史。这种电视是地面电视，用无线传输，需要室内天线或室外天线。这个电视有8个换台的按钮，按钮右侧是能打开的，里面还可以对信号和色彩进行细调。我上初中就住校了，每周回来一两次，走的时候有点舍不得电视，经常看过下午山东台的“广告文艺”之后再返校。",[210,236,237],{},[223,238],{"alt":120,"src":239},"\u002Fimages\u002Fposts\u002F2022\u002F10\u002Fchanghong14.jpg",[214,241,242],{"id":242},"卫星电视",[210,244,245],{},"上高中没看过电视，大学也尽看录像和电影了。2005年我去北京工作，开始迷上卫星电视。当时我住在北三环蓟门桥边上的明光北里小区，有个朝南的阳台，对面楼下就是中国政法大学的本部。在一个不满两平米的阳台上，我开始自己的烧星历史。",[210,247,248],{},[223,249],{"alt":120,"src":250},"\u002Fimages\u002Fposts\u002F2022\u002F10\u002FCIMG5074-768x1024.jpg",[210,252,253],{},"用电风扇架撑起来的天线，最高点为高频头",[210,255,256],{},"卫星接收机是dm500s，前面还用过一台机器是什么型号我忘记了。卫星电视很多不是免费的，需要收视卡。收视卡是很贵的，一个卫星上的收视卡大概要一两千块钱吧。在我盗版国，他们想出了一个方案。就是只买一张正版卡，放在一个服务器里，然后所有的接收机上联网，去读取那个正版卡上的账号信息。",[210,258,259],{},[223,260],{"alt":120,"src":261},"\u002Fimages\u002Fposts\u002F2022\u002F10\u002F%E6%88%AA%E5%B1%8F2022-10-04-14.48.48.jpg",[210,263,264],{},"用这个小小的dish天线，大概可以收几颗星。但我主要是接收138度上的亚太5C卫星上的节目。在这颗卫星上，集合了BBC\u002FCNN\u002FHBO\u002F中天\u002F东森\u002F凤凰卫视\u002F国家地理，还有CCTV的几个频道。经常收看的是台湾的一个福音电视台——好消息GOODTV。",[210,266,267],{},"有一个基督徒的访谈节目《真情部落格》是我经常看的，是让一些基督徒来讲他们的见证。有一期采访一个叫江锡铭的节目，叫《沙漠开江河》。他现场演奏了一诗自己创作的诗歌（视频45分11秒开始），我到现在都记得：",[269,270,271,274],"blockquote",{},[210,272,273],{},"不再随波逐流",[210,275,276,277,280],{},"从此跟主而走 不再随波逐流 我今回头 求主爱我 不再随波逐流",[278,279],"br",{},"\n从前迷途 不知回头 耶稣为我代求 从此从此 浪子回头 耶稣仍然爱我",[210,282,283],{},"李晶玉主持的《真情部落格》",[210,285,286,287,293,296],{},"这个电视台还放很多证道的节目，比如说“约尔欧斯汀”（",[288,289],"a",{"href":290,"rel":291},"https:\u002F\u002Fwww.joelosteen.com\u002F",[292],"nofollow",[288,294,290],{"href":290,"rel":295},[292],"）的证道，后来才体会到这才是标准的成功神学的证道。",[210,298,299],{},"那为什么不用youtube？Youtube2005年才成立，节目源也没多少啊。",[214,301,302],{"id":302},"机顶盒",[210,304,305],{},"2012年，开始流行一个叫“麦格TV”的IPTV盒子。我从1代用到了3代。它大概的原理是：在香港、台湾或大陆某地对一些卫星电视或有线电视的信号源进行采集，然后通过视频流的方式转播。大概能收一两百个电视台，包括欧美、港台和中国大陆的各大卫视。所以，这个盒子当时不仅在中国大陆，包括全世界的华人电视爱好者都在使用。",[210,307,308],{},[223,309],{"alt":120,"src":310},"\u002Fimages\u002Fposts\u002F2022\u002F10\u002FIMG_0649-1024x683.jpg",[210,312,313],{},"调试机器中，白色的盒子为麦格第一代",[210,315,316],{},[223,317],{"alt":120,"src":318},"\u002Fimages\u002Fposts\u002F2022\u002F10\u002FmicroMsg.1411716082127-1024x576.jpg",[210,320,321],{},"节目源很多，右下为第二代",[210,323,324],{},"2014年下半年，第三代产品H3D型号推出后，不到一年时间，香港和大陆两地开始对这种盗版方式进行打击。服务器被关闭。",[210,326,327],{},[223,328],{"alt":120,"src":329},"\u002Fimages\u002Fposts\u002F2022\u002F10\u002F20130802_214647-1024x768.jpg",[210,331,332],{},"有时候不是很稳定",[210,334,335],{},"2020年底，有一天我突然接到了原来加的一个麦格代理的QQ消息，问我还记不记得他。那几天他刚刚出狱，5年与世隔绝，他怕世界已经把他忘记了。",[210,337,338],{},[223,339],{"alt":120,"src":340},"\u002Fimages\u002Fposts\u002F2022\u002F10\u002FWechatIMG10-1-770x1024.jpeg",[214,342,343],{"id":343},"网络电视",[210,345,346],{},"2014年android tv才开始发行，可以说这是一套操作系统，我买了几个基于androidtv的小米盒子，印象最深的是小米盒子3增强版。它可以用root的方式安装谷歌框架，从而安装youtube观看。但后来由于小米公司对用户安装的软件进行审查并且偷偷删除，弃用了。",[210,348,349],{},"Mibox s 国际版是小米公司推出的一款针对国外市场的电视盒子，除了传统收看youtube之外，有netflix的认证，可以收看netflix。记得第一次把netflix安装好之后，兴奋了好一阵子。",[210,351,352],{},[223,353],{"alt":120,"src":354},"\u002Fimages\u002Fposts\u002F2022\u002F10\u002FIMG_6883-1024x644.jpg",[210,356,357],{},"2019年，第一次使用netflix",[210,359,360],{},"今年，在给一个朋友推荐电视盒子的时候，发现mibox s 已经不太流行了。谷歌在电视棒chromecast上内置了google tv，推出了chromecast with google tv。售价39.99美元，国内的价格，不足400人民币。",[210,362,363],{},[223,364],{"alt":120,"src":365},"\u002Fimages\u002Fposts\u002F2022\u002F10\u002Fchromecastwithgoogletv-1024x744.webp",[210,367,368],{},"Chromecast除了外表漂亮以外，界面也非常美观。如果你能有一个美国的ip地址，可以看到这个有很多选项的界面。如果是非美国的ip，则是一个非常简洁的界面。",[210,370,371],{},[223,372],{"alt":120,"src":373},"\u002Fimages\u002Fposts\u002F2022\u002F10\u002FIMG_2374-1024x576.jpg",[210,375,376],{},"使用美国ip的界面",[210,378,379],{},"并且，美国的用户，会内置pluto tv里的电视台。大概有上百个电视台可以播放。",[210,381,382],{},[223,383],{"alt":120,"src":384},"\u002Fimages\u002Fposts\u002F2022\u002F10\u002FIMG_2375-1024x576.jpg",[210,386,387],{},"pluto tv提供的免费直播电视台",[210,389,390],{},"作为漫威和国家地理的粉丝，我订阅了disney+，有五个部分的电视节目可以收看：disney迪斯尼\u002Fpixar皮克斯\u002FMarvel漫威\u002FStar Wars星战\u002F国家地理（根据ip可能会有变化）。Disney+是值得订阅的，虽然它对ip的要求是非常严苛的。",[210,392,393],{},[223,394],{"alt":120,"src":395},"\u002Fimages\u002Fposts\u002F2022\u002F10\u002FIMG_2378-1024x608.jpg",[210,397,398],{},"disney+ 的界面",[214,400,401],{"id":401},"结语",[403,404,405,409,412],"ol",{},[406,407,408],"li",{},"电视媒体的重要作用是传递信息，获取信息是人的基本权利。",[406,410,411],{},"我不认为谁坐在高位上都一样。如果毛再活四十年，我应该看不到除了中国以外的电视节目，跟在朝鲜的状态差不多。",[406,413,414],{},"改革开放给了我机会，让我更多知道这个世界。",{"title":120,"searchDepth":416,"depth":416,"links":417},2,[418,420,421,422,423,424],{"id":216,"depth":419,"text":216},3,{"id":231,"depth":419,"text":231},{"id":242,"depth":419,"text":242},{"id":302,"depth":419,"text":302},{"id":343,"depth":419,"text":343},{"id":401,"depth":419,"text":401},"md","\u002Fimages\u002Fposts\u002F2022\u002F10\u002Flihuanying_tv.jpg",{},true,"\u002Fzh\u002Fblog\u002Fmy-personal-history-with-television-media",{"title":171,"description":172},"publish","zh\u002Fblog\u002Fmy-personal-history-with-television-media",[],"6_grJa8ywPm9gfO8x9SGlVavBog5SuZAgUsh__Ps3OA",[436,439],{"title":161,"path":437,"stem":438,"slug":160,"date":163,"children":-1},"\u002Fzh\u002Fblog\u002Fmy-son-ye-jiale","zh\u002Fblog\u002Fmy-son-ye-jiale",{"title":180,"path":440,"stem":441,"slug":179,"date":182,"children":-1},"\u002Fzh\u002Fblog\u002Fformat-specification-for-chinese-sermon-documents-first-draft","zh\u002Fblog\u002Fformat-specification-for-chinese-sermon-documents-first-draft",1790607994012]