7 月的 AI 工程构建日志 包括公开发布、受控测试、内部构建，以及有意不发布的项目。真正有价值的部分在于它们之间的边界，因为软件很少会沿着一个干净的状态流转。
这份日志记录了哪些内容触达了用户，哪些仍留在 TestFlight 中，哪些我只在模拟器或 debug 构建中验证过，以及哪些仍处于阻塞状态。我对“交付”的定义很严格。本地构建不等于公开发布。测试通过不等于用户采用。公开列表不等于收入。一个阻止任何内容发送的审批门槛，可能正是正确的生产结果。
这个月背后的实践规则是发布纪律：定义状态，从外部验证构建产物，并在功能失败时控制影响范围。
2026 年 7 月 AI 工程构建日志概览
| 结果 | 状态 | 证据 | 经验 |
|---|---|---|---|
| --- | --- | --- | --- |
| Memento Capture 2.3.7 | 公开 | 已签名并经过公证的 DMG、同步的 manifest 和网站、全新下载验证 | 验证用户实际收到的构建产物 |
| Mix Analyzer 音乐调性检测 | 已上线 | 使用 24 个受控的已知调性进行大小调检测 | 受控输入胜过方便的个案轶事 |
| Mix Analyzer token 恢复 | 已上线 | 失败分析恢复可见且限定到所属用户 | 恢复机制属于产品契约 |
| Kiddays 等候名单 | 已上线 | 双重 opt-in，以及英语和瑞典语路由、canonicals 和 sitemap | 同意与发现应一起交付 |
| Kiddays Premium 构建 74 | 内部 TestFlight | 包含 166 个测试的内部构建；购买、恢复、试用期结束和 App Review 仍待完成 | 测试数量证明覆盖工作的投入，而非发布影响 |
| 内部 CRM 潜在客户列表 | 已上线 | 经过移动端验证的列表、搜索和五个快捷筛选器，采用可安全升级的实现 | 管理工具同样需要发布纪律 |
| 两个 Apify SEO Actors | 公开 | 评分和重写 Actors 会拒绝空输入 | 公开可用不等于实现变现 |
| BroTider onboarding 构建 27 | 仅限内部 TestFlight | 经过模拟器验证的 onboarding 构建 | 内部分发不等于 App Store 发布 |
| FactCheck、outreach、Frame Insight | 阻塞或仅限 debug | 没有发布 FactCheck，没有发送 outreach，Frame Insight 保持在 debug 后门之后 | 诚实地标注未发布状态可以避免虚假声明 |
Memento Capture 2.3.7 必须经受公开发布流程的检验
我以经过签名和公证的 DMG 形式发布了 Memento Capture 2.3.7。只有在发布流程的其余部分与这一说法一致后，这句话才真正有用。我同步了更新 manifest 和网站，然后执行全新下载并验证结果。
本地归档可能是正确的，但公开网站可能提供旧文件，或者 manifest 可能指向其他位置。发布版本是访客可以从 Memento Capture 下载页面 下载的构建产物，而不是我电脑上的文件。如果下载的构建需要后续支持，Memento Capture 支持页面 就是公开交接入口。
当我让网站可以被 agents 调用时，同样的原则也适用：API 响应或构建成功还不够。公开状态必须与预期状态一致。我在如何构建一个 agent-ready 网站→中介绍过这种方法。
Mix Analyzer 通过受控证据和可见恢复机制得到改进
调性检测：先获取受控证据
Mix Analyzer 的调性检测工作很容易被夸大，因此我限制了声明范围。我使用 24 个预先知道调性的受控和弦进行测试了大小调检测。这为我提供了一组可重复的输入，以及明确的预期答案。
24 个和弦进行并不能证明普遍准确性。它们没有覆盖每一段录音、借用和弦、转调或制作风格。它们只能验证在一组受控输入下，结果朝正确方向发展。相关方法和限制记录在大小调检测更新中，发布状态则显示在 Mix Analyzer 更新日志中。
我无法重新测试最初的两首歌曲，因为这些文件已经无法获取。我会保留这个缺口，而不是用自信的重构来替代它。如果输入无法复现，旧案例就不能成为新证据。
失败分析恢复：可见且限定到所属用户
这个月还加入了失败分析的线上恢复路径。Token 恢复现在可见且限定到所属用户，因此可以看到恢复状态，并且该状态会与正确的账户保持关联。
我的规则是在运行前定义预期结果，并将受控测试通过与生产声明分开。我在真实工作中对 AI 模型进行基准测试→时使用这一框架，它同样适用于音频分析。
Kiddays 发布了公开等候名单，而 Premium 仍留在内部
等候名单：公开
Kiddays 在 7 月有两种发布状态。等候名单已公开，包含双重 opt-in、英语和瑞典语路由、正确的 canonicals，以及 sitemap 覆盖。用户同意、交付、本地化和搜索发现必须保持一致。
双重 opt-in 可以防止某人仅仅因为输入了一个电子邮件地址，就让该地址变成活跃订阅。Canonicals 定义本地化页面之间的关系，而 sitemap 让这些页面能够被发现。我曾单独撰写过关于这类发布背后的安全 beta 等候名单模式→。
Premium：内部 TestFlight
Kiddays Premium 没有达到相同状态。构建 74 可通过内部 TestFlight 使用，并拥有一个包含 166 个测试的测试套件。购买、恢复行为、试用期结束和 App Review 仍待完成。我不会把它称为 App Store 发布、已完成的订阅系统或客户结果。
166 这个数字描述的是验证范围。它没有说明会有多少人使用 Premium，购买流程是否会通过审核，或者产品是否创造了价值。测试可以表明已知行为仍然保持正常，但不能替代分发、审核或真实使用。
更安静的发布仍然改变了日常运营
内部 CRM：已上线但保持私有
我在一个未命名的内部 CRM 中交付了潜在客户列表改进。线上结果经过移动端验证，包含搜索和五个快捷筛选器。我保持实现具备升级安全性，因此它不依赖于编辑一个脆弱的核心界面，避免之后被覆盖。
这不是一次公开产品发布，客户背景也会保持私密。内部管理软件同样值得像面向客户的页面一样认真对待。当员工同时使用桌面端和手机时，一个在桌面端正常、在手机上失败的列表就是未完成的。
Apify Actors：公开，但未变现
我还在 Apify 上公开了我的前两个 SEO Actors。其中一个为文章进行 SEO 评分，另一个支持重写。两者都会拒绝空输入，而不是为无法产生有用结果的请求消耗资源。公开意味着人们可以找到这些 Actors，但不意味着它们已经产生收入、获得采用，或证明了市场需求。
BroTider：仅限内部
BroTider onboarding 构建 27 达到了另一个受限状态：经过模拟器验证，并通过 INTERNAL_ONLY TestFlight 路径分发。它不是 App Store 发布。模拟器验证为我提供了该环境中 onboarding 的证据，而不是全设备行为或公开就绪状态的证据。
有三件事没有发布，而这也是工作的一部分
FactCheck 仍处于阻塞状态。我没有把尚未解决的发布状态变成发布公告。
outreach 工作流没有发送任何内容，因为审批门槛阻止了它。这正是预期行为。起草内容和准备收件人并不授权发送外部消息。一个在执行重要操作前暂停的系统，即使发送数量为零，也仍然有用。我关于确定性的 AI agent 权限→的文章解释了这一原则：模型可以提出操作，但是否执行由策略和所有者决定。
Memento Frame Insight 仍然仅限 debug。Debug 输出可以证明某条路径被执行，并暴露错误假设。它不是面向用户的功能、受支持的工作流，也不是对该功能将原样发布的承诺。
我希望月度日志保留这些未发布项目。删除它们会让这个月看起来更整洁，却会让工程记录失去价值。
7 月改变了我的发布方式
这个月总结出了四条规则。
最后一条规则也影响了我对轨迹级 sandbox 控制→的思考。长时间运行的自动化有很多机会找到由多个单独看来合理的控制措施组成的薄弱组合。较小的范围和独立验证可以降低这种风险。
构建和测试数量之所以出现在这里，是因为它们展示了我检查过什么。它们不是影响指标。提交数量衡量的是代码仓库活动。测试数量衡量的是一个定义好的测试套件。构建编号标识的是一个构建产物。没有单独的证据，它们都无法告诉我采用率、满意度、收入或用户价值。
证据与审核说明
在保存这份草稿前，我检查了公开的 Memento 下载和支持页面、Mix Analyzer 的更新日志和产品更新，以及我的 Apify 个人资料。内部 TestFlight、阻塞和仅限 debug 的项目仍按相应状态标注。这些来源可以确定发布状态，但不能证明采用率或收入。
哪些内容会延续到 8 月
8 月开始时面对的是尚未完成的边界，而不是一份新的承诺清单。Kiddays Premium 仍需要完成购买、恢复、试用期结束和 App Review 工作，之后我才能将其描述为已公开发布。BroTider 在任何 App Store 声明之前，仍需要超越模拟器验证和内部 TestFlight 的证据。FactCheck 仍处于阻塞状态，直到其发布条件发生变化。Frame Insight 在离开仅限 debug 状态之前，仍然只是一个实验。
对于 Mix Analyzer，受控调性集合仍然是我拥有的证据。那两首无法获取的原始歌曲仍然是一个明确缺口，除非这些输入再次可用。
我会继续遵循同一条报告规则：说明发生了什么变化，附上我拥有的最有力证据，并将没有证据支持的结果留空。如果你正在构建类似的 AI、应用或自动化系统，欢迎继续关注，或者给我留言，告诉我哪个发布边界最让你困扰。