返回 DeepSeek-TUI-2026
PROMPT_ANALYSIS.md
根目录 / PROMPT_ANALYSIS.md
1 # System Prompt Analysis — "Mismanaged Genius" Hypothesis
2
3 ## Methodology
4
5 Read every prompt layer (`base.md`, mode overlays, personality, approval policies),
6 traced the assembly logic in `prompts.rs`, and compared against what DeepSeek V4 can
7 actually do vs what the prompt currently encourages.
8
9 ---
10
11 ## Summary: The Prompt Is Cautious, Not Strategic
12
13 The current prompt has excellent safety rails — clear "when NOT to use" guidance,
14 anti-hallucination instructions, and decomposition philosophy. But it treats the
15 model's most powerful capabilities (RLM, sub-agents, parallel tool execution) as
16 **specialty escape hatches** rather than **default strategic tools**. The result:
17 a capable model that hesitates to parallelize, underuses its fan-out abilities, and
18 serializes work that could be done concurrently.
19
20 The prompt was written when the model was less reliable and needed guardrails. V4
21 models can handle more autonomy — the prompt should reflect that.
22
23 ---
24
25 ## Gap-by-Gap Analysis
26
27 ### Gap 1: RLM Is Framed as a Last Resort, Not a Strategic Tool
28
29 **Current text** (`base.md`, "RLM Is a Specialty Tool"):
30 > `rlm` is for one specific shape of work: a long input that genuinely does not fit
31 > in your context. Reach for it ONLY when direct reasoning over the input is impossible
32 > because of its size.
33
34 **Problem**: RLM is actually three tools in one:
35 1. Chunk-and-process for long inputs (the only case the prompt acknowledges)
36 2. Parallel `llm_query_batched` for multi-angle analysis (e.g., "classify these 20 items")
37 3. `rlm_query` for recursive decomposition of problems that benefit from sub-LLM critique
38
39 The prompt actively discourages cases 2 and 3. A model that could classify 20 files in
40 parallel instead reads them one at a time. A model that could get a "second opinion" on
41 its reasoning from a sub-LLM instead trusts its first pass.
42
43 **Suggested rewrite** — replace the restrictive framing with a capability guide:
44
45 ```
46 ## RLM — When to Use It
47
48 RLM loads input into a Python REPL where you write code that calls sub-LLM helpers
49 (`llm_query`, `llm_query_batched`, `rlm_query`). Three patterns, not one:
50
51 **CHUNK** — A single input that genuinely doesn't fit in your context window (a whole file
52 > 50K tokens, a long transcript, a multi-document corpus). Split it, process each chunk,
53 synthesize.
54
55 **BATCH** — Many independent items that each need LLM attention (classify 20 entries,
56 extract fields from 30 documents, score 15 candidates). Use `llm_query_batched` for
57 parallel execution — it fans out to the same DeepSeek client and finishes in one turn
58 what would take 15 sequential reads.
59
60 **RECURSE** — A problem that benefits from decomposition + critique. Use `rlm_query` to
61 have a sub-LLM review your reasoning, identify gaps, or explore alternative approaches.
62 The sub-LLM returns a synthesized answer you verify against live tool output.
63
64 **When NOT to use RLM**: a single short file you can read directly; a simple
65 classification on 3 items; interactive iterative exploration (RLM is one-shot batch).
66 For those, `read_file`, `grep_files`, or `agent_spawn` are faster and cheaper.
67 ```
68
69 ### Gap 2: Sub-Agents Are "Implementation, Not Exploration"
70
71 **Current text** (`base.md`, "When NOT to use `agent_spawn`"):
72 > You haven't first laid out a plan with `checklist_write`. Sub-agents are
73 > implementation, not exploration.
74
75 **Problem**: This directly contradicts the Plan mode prompt, which correctly says
76 "Spawn read-only sub-agents for parallel investigation." But the Agent mode prompt
77 gets the restrictive version. The result: in Agent mode (where most work happens),
78 the model treats sub-agents as a last step ("now implement the plan") rather than a
79 discovery tool ("investigate these 4 things in parallel to understand the problem").
80
81 **Reality**: Sub-agents are the BEST tool for parallel exploration. A single
82 `agent_spawn` call that fans out to 3 read-only children investigating different
83 modules is faster AND more thorough than reading them sequentially.
84
85 **Suggested rewrite** — move sub-agent guidance from "when NOT to use" to a positive
86 section:
87
88 ```
89 ## Sub-Agent Strategy
90
91 Sub-agents are cheap — DeepSeek V4 Flash costs $0.14/M input. Use them liberally for
92 parallel work:
93
94 - **Parallel investigation**: When you need to understand 3+ independent files or
95 modules, spawn one read-only sub-agent per target. They run concurrently and return
96 structured findings you synthesize.
97
98 - **Parallel implementation**: After a plan is laid out (`checklist_write` +
99 `update_plan`), spawn one sub-agent per independent leaf task. Each does one
100 thing well; you integrate results.
101
102 - **Solo tasks**: A single read, a single search, a focused question — do these
103 yourself. Spawning has overhead; one-turn reads are faster direct.
104
105 - **Sequential work**: If step B depends on step A's output, run A yourself, then
106 decide whether to spawn B based on what A found.
107 ```
108
109 ### Gap 3: No "Batch Everything" Instinct
110
111 **Current text** (`base.md`, "Your V4 Characteristics"):
112 > **Parallel execution.** Batch independent reads, searches, and greps into a single
113 > turn. Never serialize operations that can run concurrently — parallel tool calls
114 > share the same turn and finish faster.
115
116 **Problem**: This instruction is correct but buried in a V4 Characteristics section
117 the model may not internalize as a behavioral rule. The model often fires one tool,
118 waits for the result, then fires another — even when both are independent.
119
120 **Suggested addition** — add a concrete heuristic at the top of the toolbox section:
121
122 ```
123 ## Parallel-First Heuristic
124
125 Before you fire any tool, scan your plan: is there another tool you could run
126 concurrently? If two operations don't depend on each other, batch them. Examples:
127
128 - Reading 3 files → 3 `read_file` calls in one turn
129 - Searching for 2 patterns → 2 `grep_files` calls in one turn
130 - Checking git status AND reading a config → `git_status` + `read_file` in one turn
131
132 The dispatcher runs parallel tool calls simultaneously. Serializing independent
133 operations wastes the user's time and your context budget.
134 ```
135
136 ### Gap 4: Thinking Budget Too Conservative for V4
137
138 **Current text** (`base.md`, "Thinking Budget"):
139 | Task type | Thinking depth | Rationale |
140 |-----------|---------------|-----------|
141 | Simple factual lookup | Skip | Answer is immediate |
142 | Code generation (single function) | Light | Pattern-matching |
143
144 **Problem**: V4 models have 1M context and produce thinking tokens that improve
145 output quality even for "simple" tasks. Skipping thinking on a factual lookup is
146 correct. But "Light" for code generation understates the value of thinking — a
147 30-second think before writing a function catches edge cases, checks against
148 project conventions, and prevents rework.
149
150 **Suggested rewrite** — bump the defaults up one tier:
151
152 | Task type | Thinking depth | Rationale |
153 |-----------|---------------|-----------|
154 | Simple factual lookup (read, search) | Skip | Answer is immediate |
155 | Tool output interpretation | Light | Verify result matches intent |
156 | Code generation (single function) | Medium | Conventions, edge cases, context fit |
157 | Multi-file refactor | Medium | Cross-file dependencies |
158 | Debugging (error to root cause) | Deep | Hypothesis generation |
159 | Architecture design | Deep | Trade-offs, constraints |
160 | Security review | Deep | Adversarial reasoning |
161
162 ### Gap 5: No "Verify Before Claiming" Pattern
163
164 **Current state**: The subagent output format (`subagent_output_format.md`) has an
165 EVIDENCE section that requires concrete artifact citations. This is excellent. But
166 the main prompt (`base.md`) doesn't establish this as a general habit.
167
168 **Problem**: The model sometimes reads a file, then writes a patch based on its
169 memory of the file rather than re-reading the specific lines it's changing. Or it
170 claims a shell command succeeded based on exit code 0 without checking the output.
171
172 **Suggested addition** — add to the "Decomposition Philosophy" section:
173
174 ```
175 ## Verification Principle
176
177 After every tool call that produces a result you'll act on, verify before
178 proceeding:
179 - File reads: confirm the line numbers you're about to patch are what you think
180 - Shell commands: check stdout, not just exit code
181 - Search results: confirm the match is what you expected
182 - Sub-agent results: cross-check one finding against a direct `read_file`
183
184 Don't claim a change worked until you've observed evidence. Don't trust memory
185 over live tool output.
186 ```
187
188 ### Gap 6: No Composition Heuristic for Complex Work
189
190 **Current state**: The prompt says "For complex initiatives, layer `update_plan`
191 above `checklist_write`." This is correct but vague. The model sometimes creates
192 a plan, creates a checklist, and then works through the checklist without
193 re-evaluating the plan.
194
195 **Suggested addition**:
196
197 ```
198 ## Composition Pattern for Multi-Step Work
199
200 For any task estimated to take 5+ steps:
201
202 1. `update_plan` — 3-6 high-level phases (status: pending)
203 2. `checklist_write` — concrete leaf tasks under the first phase (mark first
204 `in_progress`)
205 3. Execute phase 1, updating checklist as you go
206 4. After each phase completes, re-read your plan: does phase 2 still make sense?
207 Update the plan if new information changes the approach.
208 5. When a phase reveals sub-problems, add them to the checklist or spawn
209 investigation sub-agents — don't guess.
210 ```
211
212 ### Gap 7: Approval Mode Contradiction
213
214 **Current state**: The Agent mode approval policy says "Any write, patch, shell
215 execution, sub-agent spawn, or CSV batch operation will ask for approval first."
216 But the "Key principle" says "make your work visible" and encourages
217 `checklist_write` to populate the sidebar.
218
219 **Problem**: In Agent mode, the model often waits for approval on EACH step
220 individually. A batch of 3 `edit_file` calls requires 3 separate approval rounds.
221 The prompt should encourage batching approvals: present the full plan, get
222 approval once, then execute all writes in parallel.
223
224 **Suggested addition** — add to the Agent mode overlay:
225
226 ```
227 ## Efficient Approvals
228
229 When your plan includes multiple writes, present them together:
230 1. Show `checklist_write` with all write steps listed
231 2. Request approval for the batch ("I need to make 3 edits across 2 files...")
232 3. Once approved, execute all writes in one turn (parallel `edit_file` /
233 `apply_patch` calls)
234
235 Don't sequence approvals one at a time. The user wants context, not interruption.
236 ```
237
238 ---
239
240 ## Concrete Prompt Changes
241
242 ### 1. `base.md` — Replace "RLM Is a Specialty Tool" section
243
244 Remove the current restrictive "RLM Is a Specialty Tool" section entirely.
245 Replace with the "RLM — When to Use It" section from Gap 1 above.
246
247 ### 2. `base.md` — Replace "When NOT to use `agent_spawn`"
248
249 Remove the bullet about sub-agents from the "When NOT to use" section.
250 Move it to a new positive "Sub-Agent Strategy" section (Gap 2 above) placed
251 immediately after the "Decomposition Philosophy" section.
252
253 ### 3. `base.md` — Add "Parallel-First Heuristic"
254
255 Insert after the toolbox reference section, before "When NOT to use."
256 (Gap 3 above.)
257
258 ### 4. `base.md` — Bump thinking budget defaults
259
260 Change the "Code generation (single function)" row from Light → Medium.
261 (Gap 4 above.) Single-line change.
262
263 ### 5. `base.md` — Add "Verification Principle"
264
265 Insert as a sub-heading under "Decomposition Philosophy."
266 (Gap 5 above.)
267
268 ### 6. `base.md` — Add "Composition Pattern"
269
270 Insert as a sub-heading under "Decomposition Philosophy," after
271 "Verification Principle."
272 (Gap 6 above.)
273
274 ### 7. `modes/agent.md` — Add "Efficient Approvals"
275
276 Insert at the end of the Agent mode overlay.
277 (Gap 7 above.)
278
279 ---
280
281 ## What NOT to Change
282
283 - **"When NOT to use `exec_shell`"** — this guidance is correct and important.
284 Typed tools beat shell-outs for reliability.
285 - **"When NOT to use `edit_file` / `apply_patch`"** — tool selection rules are
286 good and prevent blind patching.
287 - **Preamble rhythm** — the tone guidance is well-calibrated.
288 - **Output formatting** — terminal constraints are real; the guidance is correct.
289 - **Context management** — the ~80% compaction suggestion is practical.
290 - **Sub-agent sentinel protocol** — the integration pattern is well-defined.
291
292 ---
293
294 ## Risk Assessment
295
296 **Risk: Over-parallelization**. A model told to "batch everything" might spawn
297 sub-agents for trivial reads. Mitigation: the "Solo tasks" bullet in the new
298 sub-agent strategy section explicitly says "do these yourself."
299
300 **Risk: Over-thinking**. Bumping the thinking budget might waste tokens on
301 simple code generation. Mitigation: "Medium" for single-function generation is
302 still conservative; the model can self-regulate with the existing guidance
303 "skip for lookups."
304
305 **Risk: RLM over-use**. Framing RLM as a strategic tool might cause inappropriate
306 use for tasks better served by `agent_spawn`. Mitigation: the new "When NOT to
307 use RLM" bullet covers the common failure modes.
308
309 **Risk: Cache busting**. Adding text to the system prompt changes its byte
310 representation, which busts the prefix cache for the first turn after the change.
311 Mitigation: this is a one-time cost; subsequent turns hit the cache at the new
312 prompt boundary.
313
313 lines MARKDOWN