references/honest_output_discipline.md
9.6 KB查看排版效果| 1 | # Honest Output Discipline — Why Manufactured Problems Are Worse Than Validation |
| 2 | |
| 3 | This reference answers exactly one decision: **why does the reflect skill explicitly refuse to manufacture problems when the conversation is genuinely on track, and how does it deliver validation honestly?** |
| 4 | |
| 5 | ## The Core Rule |
| 6 | |
| 7 | Reflection is supposed to surface issues. So there's pressure to find issues — even when none exist — because "found a problem" feels like the reflection did its job. |
| 8 | |
| 9 | **This is wrong.** Manufactured problems are worse than honest validation because: |
| 10 | |
| 11 | 1. They waste the user's attention on non-issues |
| 12 | 2. They erode trust in real future findings ("the last reflection invented problems; this one might too") |
| 13 | 3. They reward the appearance of rigor over actual rigor |
| 14 | |
| 15 | When the conversation is genuinely on track, the honest output is: **"This is solid because X. Continue."** With specific reasoning, not vague reassurance. |
| 16 | |
| 17 | ## The Two Failure Modes |
| 18 | |
| 19 | ### Failure 1: Manufactured Problems |
| 20 | |
| 21 | > "I notice some potential drift in the conversation. We might want to consider whether the framing has shifted slightly. There could be implicit assumptions worth questioning." |
| 22 | |
| 23 | This is vague pessimism. No specific evidence. No actionable correction. The reader can't tell whether the reflection found something real or padded the output. |
| 24 | |
| 25 | ### Failure 2: Vague Reassurance |
| 26 | |
| 27 | > "Looks good! You're on the right track. Keep going." |
| 28 | |
| 29 | This is vague optimism. Also no specific evidence. The reader can't tell whether the reflection actually re-read the conversation or just rubber-stamped it. |
| 30 | |
| 31 | **Both failure modes are unhelpful for the same reason: they don't cite specific evidence.** |
| 32 | |
| 33 | ## Honest Validation (When Path Is Solid) |
| 34 | |
| 35 | The correct shape: |
| 36 | |
| 37 | > "Re-reading from the original goal at turn 3 — clarify the auth flow — the current direction is solid. Three specific reasons: |
| 38 | > |
| 39 | > First, the auth flow has been narrowed from generic OAuth to a specific Google + GitHub combination at turn 9, which matches your stated user base. |
| 40 | > |
| 41 | > Second, the bias check finds no anchoring (you explicitly considered passwordless at turn 11 and rejected it for reasons specific to your team's expertise). |
| 42 | > |
| 43 | > Third, the original goal connects directly to the current implementation — no drift detected. |
| 44 | > |
| 45 | > Continue." |
| 46 | |
| 47 | This validation is honest because: |
| 48 | |
| 49 | - **Cites specific evidence** (turn numbers, specific decisions) |
| 50 | - **Names what was checked** (drift, anchoring, goal-connection) |
| 51 | - **Reaches a clear conclusion** (Continue, not "looks good") |
| 52 | - **Doesn't pad** with manufactured concerns |
| 53 | |
| 54 | ## Honest Critique (When Path Has Drifted) |
| 55 | |
| 56 | The correct shape: |
| 57 | |
| 58 | > "Re-reading from the original goal at turn 3 — reduce onboarding friction — significant drift has occurred. |
| 59 | > |
| 60 | > At turn 3 the goal was reducing time-to-first-action. By turn 11 the focus shifted to a comprehensive feature flag system. The two are related (feature flags COULD reduce friction) but the conversation has been adding feature-flag complexity without re-checking whether feature flags are the right intervention for friction. |
| 61 | > |
| 62 | > The bias check surfaces complexity bias: each feature-flag layer added is plausible but cumulatively the system is more complex than the original problem warranted. The team is solving the feature-flag problem, not the friction problem. |
| 63 | > |
| 64 | > Pivot toward: revisit the original friction problem at turn 3. Three of the seven friction sources don't need feature flags at all — they need UI simplification. Drop the feature-flag work for those three. Keep feature flags only for the two friction sources where multiple paths legitimately need to be tested." |
| 65 | |
| 66 | This critique is honest because: |
| 67 | |
| 68 | - **Specific evidence** of drift (turn 3 vs turn 11) |
| 69 | - **Names the bias** that explains it |
| 70 | - **Recommends specific pivot** (not "consider alternatives") |
| 71 | - **States what to drop** (not just what to add) |
| 72 | |
| 73 | ## When Path Is Mixed |
| 74 | |
| 75 | Some reflection outputs are genuinely mixed — parts on track, parts drifted. The honest shape acknowledges both: |
| 76 | |
| 77 | > "Re-reading from turn 3 — the core direction is solid but two specific concerns have emerged. |
| 78 | > |
| 79 | > Solid: {evidence-anchored validation}. Continue this thread. |
| 80 | > |
| 81 | > Concern 1: {specific evidence-anchored concern with corrective}. |
| 82 | > |
| 83 | > Concern 2: {specific evidence-anchored concern with corrective}. |
| 84 | > |
| 85 | > Recommendation: continue the core direction but pause briefly to address concern 1 before continuing." |
| 86 | |
| 87 | The structure mirrors reality. Don't force a single Continue/Pivot/Pause when the actual finding is mixed. |
| 88 | |
| 89 | ## Why This Discipline Matters |
| 90 | |
| 91 | The reflect skill's value comes from **trust** — the user can trust that: |
| 92 | |
| 93 | - When the skill says "Continue", the path is actually solid |
| 94 | - When the skill says "Pivot", there's actually drift worth correcting |
| 95 | - When the skill says "Pause for {Q}", the question is actually decision-critical |
| 96 | |
| 97 | If the skill manufactures problems for the appearance of rigor, this trust erodes. The user starts discounting findings. Eventually, the skill becomes ceremony. |
| 98 | |
| 99 | **Honest output is the entire value proposition.** Without it, reflection is theater. |
| 100 | |
| 101 | ## The Specific-Evidence Requirement |
| 102 | |
| 103 | Every observation in a reflect output must cite specific conversation evidence: |
| 104 | |
| 105 | | ❌ Vague | ✅ Specific | |
| 106 | |---|---| |
| 107 | | "Some assumptions might be worth questioning" | "At turn 7, the assumption that X requires Y was made without checking; that's the load-bearing assumption for the current direction" | |
| 108 | | "We might be missing alternatives" | "Two alternatives surfaced at turns 4 and 8 (A and B) were dismissed; A is worth revisiting because the dismissal reasoning was based on outdated info we updated at turn 12" | |
| 109 | | "The framing could be clearer" | "The original framing at turn 3 was 'reduce onboarding friction'. By turn 11 the working framing is 'build a feature flag system'. The two are connected but not equivalent." | |
| 110 | |
| 111 | Vague observations let the reader interpret them charitably; specific observations force engagement. The discipline is asking "what evidence would you cite if challenged?" on every line. |
| 112 | |
| 113 | ## Anti-Patterns |
| 114 | |
| 115 | ### "Always find at least one problem" |
| 116 | |
| 117 | The strongest form of manufactured-problems bias. Some reflections genuinely find nothing wrong. The honest output is "this is solid because X." Inventing a problem to demonstrate "the reflection worked" is the worst version of this. |
| 118 | |
| 119 | ### "Avoid being too critical" |
| 120 | |
| 121 | Softening real findings to spare feelings. If the path has drifted, say so with evidence. The user can handle critique anchored in evidence; vague critique is what frustrates them. |
| 122 | |
| 123 | ### "Lead with reassurance, then critique" |
| 124 | |
| 125 | Compliment-sandwich structure. Honest reflection states what's solid AND what's drifted in their actual proportions, not in a politeness-balanced ratio. |
| 126 | |
| 127 | ### "End with 'consider your options'" |
| 128 | |
| 129 | Refuses to make a recommendation. The closing must be Continue / Pivot to specific X / Pause for specific Q. Telling the user "consider your options" is the same as not having reflected. |
| 130 | |
| 131 | ### "Cite biases without specific evidence" |
| 132 | |
| 133 | "Watch for confirmation bias" without naming what the bias is operating on. Either find the specific evidence + name it, or state explicitly that you checked and didn't find this bias. |
| 134 | |
| 135 | ## Operational Checklist (Per Reflection) |
| 136 | |
| 137 | - [ ] Every observation has specific conversation evidence (turn numbers or specific decision points) |
| 138 | - [ ] When validating: state specific reasons, not "looks good" |
| 139 | - [ ] When critiquing: state specific evidence + specific corrective, not "consider alternatives" |
| 140 | - [ ] When mixed: acknowledge mixed honestly; don't force single-verdict shape |
| 141 | - [ ] No manufactured problems for the appearance of rigor |
| 142 | - [ ] No vague reassurance for the appearance of approval |
| 143 | - [ ] Closing recommendation is specific (Continue why / Pivot to X / Pause for Q) |
| 144 | |
| 145 | ## Citations (7 sources) |
| 146 | |
| 147 | 1. **Steve Yegge, "Frankness over politeness" essays (various blog posts, ~2005-2015).** Source for the framing that vague optimism is worse than honest critique. Yegge's arguments for engineering culture apply directly to reflection-on-reasoning culture. |
| 148 | |
| 149 | 2. **Atul Gawande, *Better* (Holt, 2007).** Source for the discipline of stating findings with specific evidence. Gawande's medical-checklist work models how to communicate findings (good and bad) with specificity. |
| 150 | |
| 151 | 3. **Edwards Deming, *Out of the Crisis* (MIT Press, 1986).** Source for the "drive out fear" management principle that justifies honest critique over softened feedback. Deming's argument: organizations where critique is softened produce worse outcomes than ones where it's stated cleanly. |
| 152 | |
| 153 | 4. **Bertrand Russell, "The Will to Doubt" (essay, 1934).** Source for the philosophical case against vague reassurance. Russell argues that intellectual honesty requires stating uncertainty AND certainty with their actual evidence — neither over-stating nor under-stating either. |
| 154 | |
| 155 | 5. **Kim Scott, *Radical Candor* (St. Martin's, 2017).** Source for the "care personally + challenge directly" framing. Manufactured problems fail the "care personally" test (they waste the user's time); vague reassurance fails "challenge directly" (refuses to engage). |
| 156 | |
| 157 | 6. **Bret Victor, "Inventing on Principle" (talk + essays).** Source for the discipline of making thinking visible. Reflection outputs that cite specific evidence make the reflector's thinking visible; vague outputs hide it. |
| 158 | |
| 159 | 7. **The reflect skill's own anti-pattern list (megaprompt 02-reflect).** Source: explicit prohibition of "manufactured problems when things are actually fine" + "vague reassurance ('looks good!') instead of specific reasoning". The skill's design intent is direct anti-vagueness on both sides. |
文件内容是平台检查时读出的文本，只供查看。平台不会运行包里的任何脚本或程序。
