Core philosophy: product thinker mindset × ultimate single Agent × documentation-driven × quality gate closed loop
Source: Xu Keqian — from music teacher to product manager to AI-Native serial entrepreneur, founder of Piyingke, a harness engineering practitioner with hundreds of thousands of lines of self-built skills and scripts.
First Principle: Iron Law
Probability multiplication is the first principle.
The success rate of each step multiplied together determines the final quality. Even if each step is 0.99, after n=51 it still fails. Therefore: do not pursue one-shot perfection; pursue making each step verifiable, fixable, and iterable.
Corollaries:
- Diligence cannot compensate for lack of ability — model capability is the baseline; harness and skill are only accelerators and amplifiers
- Break it down until it is simple enough; only then can an individual task converge
- Every action must correspond to an eval
Second Principle: The Ultimate Single-Agent Doctrine
Do not blindly use multi-agent. Take the single agent to the extreme, then consider orchestration.
When to use a single Agent (the default choice)
- Tasks with sequential dependencies
- Long-horizon tasks that require contextual coherence
- Core processes with high quality requirements where errors are unacceptable
When to use parallel SubAgents (exceptional cases)
- Between tasksclearly no dependency relationship(such as multi-perspective audits producing reports)
- Parallel resultsare not prone to problems when merged
- You are capable of precisely controlling the context injection for each subagent
The pitfalls of parallelism
- SubAgent context injection is a trap: what to inject and how much to inject both require precise control
- The main Agent may pretend to be a SubAgent (this has actually been encountered)
- If one step in a parallel task goes wrong, the entire long task may be ruined
- Merging results easily introduces inconsistencies
Practical advice: If unsure, choose sequential execution. Slower but reliable.
Third Principle: Documentation-Driven Development (SDD)
Invest 70% of effort in documentation quality and harness, 30% in writing code.
Why documentation matters more than code
- Without writing documentation, there is no architectural view
- It is impossible to have AI scan the entire codebase every time
- Scattered features = scattered quality
- Let AI maintain a document itself, then vibe-align the code
SDD workflow
1. 需求文档(PRD/设计文档)
↓ AI辅助撰写 + 人工审核
2. 技术文档(架构决策、接口规范)
↓ AI维护 + 人工把关
3. 代码实现
↓ Agent执行 + 质量门禁拦截
4. 文档回写(代码变更 → 文档自动更新)
↓ 闭环
Documentation quality gates
Automated quality control for documentation is much harder than for code. Key points:
- Tech stack selection itself is a routine matter and can be templated
- Each feature point cannot be handled perfunctorily with only 3 use cases (if one round is not enough, do more rounds)
- But also prevent over-design — find the balance point and combine it with the project's actual situation
Fourth Principle: Quality Gate Closed Loop (Verification-Driven)
Strict quality gates = high cache hit rate = high quality = low cost.
Gate design
每个Action → 对应Eval → 通过/不通过
↓ 不通过
自动修复(最多N轮)→ 仍不通过 → 升级给人类
Eval's acceptable threshold
- Different businesses and different teams have different thresholds
- The key is to produce the expected result within the expected budget and expected time.
- Don't expect to get it right in one shot; that's a rare occurrence.
- 3 to 5 rounds of AI-Native iteration is a fairly ideal acceptable threshold.
Counterintuitive finding: burning more ≠ spending more.
The automated correction process appears to waste tokens, but in reality:
- Issues are repeatedly corrected one by one → high cache hit rate
- High cache hit rate = high quality (indicating the issues have converged)
- Cache-hit tokens cost almost nothing
Measured data: When the cache hit rate is 99%+, every 100 million tokens ≈ 8.5 RMB, which is roughly free.
Corollary: Saving tokens is actually a bad deal. Loosening token usage instead causes the actual cost to drop.
Fifth principle: product decomposition thinking
End to end is always complex; any single dimension is simple.
Decomposition methodology
- Complex problem → break into multiple layers
- Each layer → a single dimension that can be exhaustively enumerated
- Limited options in a single dimension → the model can make decisions
- Input variables (company size, scenario, constraints) → all are conditional variables
Generalization within boundaries
- Every product has boundaries
- Generalization within boundaries is not hard; it can all be exhaustively enumerated
- You don't need 100% generalization, only generalization within the target scope
- End-to-end complexity ≠ single-dimension complexity
Applicable boundaries
This method suitsproducts with clear scenarios and definable boundaries. ForAI-Native interactive products with highly unpredictable user behavior, a mechanism for rapid post-launch iteration needs to be added.
Sixth principle: outwitting AI
AI will ally with the skills and gates you write to resist your requirements.
Known AI resistance patterns
- To delete a paragraph → AI resists by renaming the paragraph, moving its position, rewriting to preserve the semantics, etc.
- Starting a new session, reopening codex, or switching computers cannot eliminate the resistance
- This phenomenon may last for several days
Countermeasures
- Bring in eval: if it doesn't meet the requirements, keep iterating (repeated deletion is also a form of iteration)
- Every action corresponds to an eval: if you're not at ease
- CICD integration logic retrospective: use the old CI/CD integration logic to retrospect on the problem
- Reduce the gacha probability: use a harness to reduce the model's gacha rate
- Compact in time: /compact once you reach about context window * 0.5, to keep your intelligence from going offline
Practical workflow template
Starting a new project
Phase 1: 文档先行(占总时间70%)
├── 撰写PRD(AI辅助 + 人工审核)
├── 技术架构文档(AI维护 + 人工把关)
├── 定义质量门禁和eval标准
└── 设计harness结构(skill + rule配置)
Phase 2: 代码实现(占总时间20%)
├── Agent顺序执行任务
├── 每个任务通过质量门禁
├── 不通过 → 自动修复 → 仍不通过 → 人工介入
└── 文档自动回写
Phase 3: 迭代收敛(占总时间10%)
├── 跑eval批量验证
├── 收集失败case → 分析 → 改进harness
└── 直到达到acceptable threshold
Daily development rhythm
1. 不用子代理(除非任务明确无依赖)
2. 顺序给任务,每个任务带eval
3. 放着跑,定期查看
4. 门禁拦住的问题 → 分析是harness问题还是模型问题
5. harness问题 → 改skill/rule
6. 模型问题 → 换模型或降低任务粒度
Model selection recommendations
Based on practical experience:
- Not purely coding: don't use the xxx-codex model, switch directly to a general-purpose model
- Stability first: slower is fine, but solid and not verbose
- Notes on domestic models:
- Entering context window * 0.4~0.5 may cause a drop in intelligence
- Use a harness to reduce the gacha rate
- Compact once you reach window * 0.5
- Long context is not omnipotent: the key is that the threshold for entering the dumb zone must be high
Cost Optimization Checklist
- ✅ Establish strict quality gates → naturally improve cache hit rate
- ✅ Loosen token usage → counterintuitively reduce costs
- ✅ Automated correction process → increasingly higher cache hit rate
- ✅ Sequential execution → avoid waste caused by parallel failures
- ✅ Timely compact → avoid rework caused by degraded intelligence
- ❌ Do not manually save tokens → this instead leads to poor quality, more rework, and higher total costs
Summary of Key Principles
"做一个马鞍,再做一个拆马鞍的工具" — 群友评价
"一抓就死,一放就乱" — 管理的永恒难题
"多烧 ≠ 多花钱" — 反直觉的真理
"端到端复杂,单维度简单" — 产品拆解的核心
"慢点就慢点,但牢靠" — 稳定性压倒一切
References
For more methodological details, please refer to:
references/sdd-framework.md— Detailed process of the SDD document-driven development frameworkreferences/eval-patterns.md— Quality gates and Eval pattern library