docs(zh-cn-explanation): 统一提示块围栏语法
我将五篇 explanation 文档里的四冒号提示块语法统一为三冒号，确保与当前文档渲染规则一致。 此前这些文档混用不同围栏写法，容易在审阅和渲染中引入不必要差异；现在统一后可减少维护噪音。 feishu: https://feishu.cn/wiki/TODO Made-with: Cursor
This commit is contained in:
leon
Alex Verkhovsky
parent
4b7d883bcd
commit
7337aeaa0a
|
|
@ -32,9 +32,9 @@ sidebar:
|
|||
3. 模型按该方法重审并展示改进
|
||||
4. 你决定采纳、丢弃、继续下一轮或结束
|
||||
|
||||
::::tip[实战建议]
|
||||
:::tip[实战建议]
|
||||
做规格、方案或计划时，先跑一次“事前复盘”通常收益最高，容易提前暴露隐藏风险。
|
||||
::::
|
||||
:::
|
||||
|
||||
## 与相近模式的区别
|
||||
|
||||
|
|
|
|||
|
|
@ -42,9 +42,9 @@ sidebar:
|
|||
|
||||
所以它本质上是**高召回、需人工分诊**的策略，而不是“自动真理机”。
|
||||
|
||||
::::caution[关键心法]
|
||||
:::caution[关键心法]
|
||||
把发现分成三类：必须修、可延后、可忽略。评审质量的关键不在“发现数量”，而在分诊质量。
|
||||
::::
|
||||
:::
|
||||
|
||||
## 与 Quick Dev 的关系
|
||||
|
||||
|
|
|
|||
|
|
@ -42,9 +42,9 @@ sidebar:
|
|||
4. **组织收敛**：按主题聚类并排序
|
||||
5. **行动化**：给重点方向定义下一步和衡量标准
|
||||
|
||||
::::note[核心原则]
|
||||
:::note[核心原则]
|
||||
想法来源于你，workflow 负责构建“更容易产生好想法”的过程。
|
||||
::::
|
||||
:::
|
||||
|
||||
## 与相近模式的区别
|
||||
|
||||
|
|
|
|||
|
|
@ -39,9 +39,9 @@ Party Mode 的价值在于“更快看见盲区”：
|
|||
- 优势：视角多、分歧显性、对齐速度快
|
||||
- 代价：讨论信息量大，需要你主动控节奏和收敛
|
||||
|
||||
::::caution[使用建议]
|
||||
:::caution[使用建议]
|
||||
先给清晰议题，再给决策约束（时间、风险、成本、成功标准），讨论质量会明显更高。
|
||||
::::
|
||||
:::
|
||||
|
||||
## 与相近模式的区别
|
||||
|
||||
|
|
|
|||
|
|
@ -75,9 +75,9 @@ Quick Dev 是执行节奏设计；`adversarial review` 是审查策略。二者
|
|||
- 目标长期模糊且频繁变化
|
||||
- 团队尚未接受“先规格后长时执行”的工作方式
|
||||
|
||||
::::tip[实践建议]
|
||||
:::tip[实践建议]
|
||||
先把成功标准写清楚，再启用 Quick Dev。目标越清楚，自动化收益越大。
|
||||
::::
|
||||
:::
|
||||
|
||||
## 继续阅读
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue