发表于 | 分类于 | 评论数： | 阅读次数：
本文字数： 12k | 阅读时长 ≈ 11 分钟

Harness Engineering 是围绕 AI Agent 设计约束机制、反馈回路、工作流控制和持续改进循环的系统工程实践。它解决的核心问题是：当 AI Agent 拥有了强大的代码生成能力后，如何确保其输出的可靠性、一致性和长期可维护性。

引言：三层工程概念的嵌套关系

Prompt Engineering、Context Engineering 和 Harness Engineering 构成了嵌套关系，而非并列概念。Phil Schmid 打了个比方：模型是 CPU，Harness 是操作系统——CPU 再强，OS 拉胯也白搭。

Prompt Engineering 解决的是”如何与模型对话”：如何编写清晰的指令、如何设计 Few-shot 示例、如何使用 Chain-of-Thought 推理。它是原子层面的交互优化。

Context Engineering 解决的是”给 Agent 看什么”：如何组织上下文窗口、如何检索相关信息、如何管理对话历史。它是会话层面的信息管理。

Harness Engineering 解决的是”系统怎么防崩、怎么量化、怎么修”：如何构建多协作系统、如何设计反馈回路、如何强制执行架构约束。它是系统层面的工程实践。

三者层层递进：Prompt Engineering 是基础，Context Engineering 在其之上构建会话管理，Harness Engineering 在更上层构建完整的开发和运维体系。mtrajan 的区分更直接：Context Engineering 管的是输入，Harness Engineering 管的是系统行为。

阅读全文 »

发表于 | 更新于 | 分类于 | 评论数： | 阅读次数：
本文字数： 12k | 阅读时长 ≈ 11 分钟

PDCA（Plan-Do-Check-Act）是戴明提出的持续改进闭环，核心思想是让每轮循环都比上一轮更聪明。复利工程把这个思想搬进 AI 编码时代：AI 不只是写代码的工具，更是把每次开发的知识固化下来的载体，让每一次工作都站在上一次的积累上。

AI 代替人写代码，这件事已经发生了。但大多数人的用法停留在「给 AI 一个需求，拿回一段代码」。这种用法有个隐患：代码在变多，但对代码库的理解没有同步增长——知识存在人脑里，人会忘、会离职，下一个人仍然踩同样的坑。

传统 PDCA 在软件工程里卡在「Act」这步。问题找到了，就是没人把改进固化成规则让所有人用上。AI 的出现让这件事的成本接近零：让 AI 总结一次 Review、写几条规则进文件，30 秒。这就是复利工程想做的事。

阅读全文 »

发表于 | 更新于 | 分类于 | 评论数： | 阅读次数：
本文字数： 27k | 阅读时长 ≈ 24 分钟

如何将 SDD（规范驱动开发）的结构化工作流与多智能体并行编排深度融合，在 AI 辅助编码中同时实现高吞吐与高可靠。

一、引言：AI 编码的效率天花板

2025 年以来，AI 辅助编码已经从”补全一行代码”进化到”端到端实现一个功能”。行业数据令人振奋——Atlassian 在全面采用 AI Agent 后测量到工程师人均 PR 数量提升了 89%；Stripe 的 Agent 系统每周自主合并超过 1000 个 PR；Rakuten 利用 AI Agent 在 7 小时内完成了 1250 万行代码库上的复杂 vLLM 实现。

但随着 AI Agent 承担的任务从单文件修改扩展到跨模块的复杂变更，一个新的瓶颈开始浮现：

单智能体顺序执行的效率天花板。

想象一下这个场景：你要给项目新增一个用户认证模块。这涉及数据模型、API 端点、中间件、前端集成和测试——至少 5-6 个相互关联的子任务。在传统的单 Agent 模式下，即便这些任务中有些彼此独立，AI 也只能一个接一个地串行执行。5 个任务各花 5 分钟，总耗时就是 25 分钟。

更致命的是质量问题。单 Agent 既当运动员又当裁判：自己写的代码自己验证，缺少独立的质量门控。研究表明，多智能体系统中 13.2% 的失败来自推理-动作不匹配，7.4% 来自任务偏离，6.8% 来自错误假设。当 Agent 对某个 API 不确定时，它可能会猜测类型、留下 TODO、甚至抑制类型检查——这些”半成品”在复杂项目中会迅速积累成技术债务。

微软研究院将 “意图形式化”（Intent Formalization） 定义为可靠 AI 编码的核心挑战——如何自动将模糊的人类意图转化为精确、可检查的规范。这恰恰是 SDD（规范驱动开发）试图解决的问题。

这驱使我们思考两个核心问题：

  1. 能不能让多个 AI 智能体并行工作，像流水线一样同时处理互不依赖的任务？
  2. 能不能在 AI 执行链路中嵌入结构化的质量门控，让”写代码”和”验代码”由不同的角色完成？

OMO-OPSX 正是对这两个问题的回答。它将 OpenSpec 的规范驱动开发（SDD）工作流与 OMO（oh-my-opencode） 的多智能体编排能力深度融合，在保持开发灵活性的前提下，实现并行加速与分层质量保障。这种融合代表了一种正在兴起的工程范式——有人称之为**”复合工程”（Compound Engineering）**：工程师的角色从”代码编写者”转变为”系统编排者”，通过设计约束、编排智能体和验证输出来实现 3-7 倍的生产力提升。

阅读全文 »

发表于 | 更新于 | 分类于 | 评论数： | 阅读次数：
本文字数： 4.4k | 阅读时长 ≈ 4 分钟

iOS页面路由,具体可能需要处理的场景、问题有：

  1. 最普通 原生页面跳转到原生页面
  2. 有多种技术栈的app，可能包含原生、h5/rn/flutter等页面。就扩展出：
    • 原生页面和h5页面互相跳转
    • 原生和rn页面互相跳转
    • 原生和flutter互相跳转等
  3. 在上述的基础上，很多原本原生实现的页面，需要通过新的H5页面进行升级/降级，或者原本PC或者H5页面，需要重定向到已有的原生页面。而这些基本都是硬编码的跳转逻辑，需要随着版本不停改动。跳转的逻辑需要根据版本迭代走，无法统一远程进行改动（例如：每次新增一个需要拦截跳转原生的页面，都需要通过发版来解决）
    • 跨技术栈跳转的实现成本比较高，必须在桥接模块中进行特殊适配。H5页面中，某些跳转需要跳转原生或者其他页面，必须要通过WebView跳转的拦截做特殊判断处理
    • 需要梳理的各技术栈跳转逻辑，将这些跳转整合，能够满足动态性、可配置的需求。
  4. 一些应用有社交分享功能，需要分享出去一个链接以打开自身app内特定页面。或者有应用内分享链接 也可以打开自身app内特定页面。
    • 一般来说 应用外打开app需要使用iOS的URL Scheme功能或者Universal links功能
阅读全文 »

发表于 | 更新于 | 分类于 | 评论数： | 阅读次数：
本文字数： 2.6k | 阅读时长 ≈ 2 分钟

探究一下我们计算app储存空间的大小时和系统设置里的差距

App自身大小差距

系统设置里App的存储空间分为：“App大小”和“文稿与数据”。

阅读全文 »

发表于 | 更新于 | 分类于 | 评论数： | 阅读次数：
本文字数： 20k | 阅读时长 ≈ 19 分钟

App里总会有很多的弹窗，为了美观，大多数弹窗都需要盖住导航栏；这时弹窗会添加到window上以满足需求。但添加到window上的弹窗却不方便管理，也与页面脱离关系，如果有异步的情况，弹窗会更加复杂难以处理，如何才能对window弹窗统一进行管理，解决这些问题？

遇到的问题

阅读全文 »

发表于 | 更新于 | 分类于 | 评论数： | 阅读次数：
本文字数： 1.9k | 阅读时长 ≈ 2 分钟

今天聊一下页面加载时间的检测。

  • viewDidappear
  • viewIsAppearing
  • 监听某个元素渲染完时间
阅读全文 »

发表于 | 更新于 | 分类于 | 评论数： | 阅读次数：
本文字数： 5.5k | 阅读时长 ≈ 5 分钟

之前介绍了一下 iOS中的编译过程 iOS编译过程 。 现在来对整体编译时间做一个优化。

编译耗时分析

xcode完整的build详细的步骤如下：

  • 创建Product.app的文件夹
  • 把Entitlements.plist写入到DerivedData里，处理打包的时候需要的信息（比如application-identifier）。
  • 创建一些辅助文件，比如各种.hmap，这是headermap文件，具体作用下文会讲解。
  • 执行CocoaPods的编译前脚本：检查Manifest.lock文件。
  • 编译.m文件，生成.o文件。
  • 链接动态库，o文件，生成一个mach o格式的可执行文件。
  • 编译assets，编译storyboard，链接storyboard
  • 拷贝动态库Logger.framework，并且对其签名
  • 执行CocoaPods编译后脚本：拷贝CocoaPods Target生成的Framework
  • 对Demo.App签名，并验证（validate）
  • 生成Product.app
阅读全文 »