Merge pull request #446 from claude-code-best/feature/prompt-cut-down

feat: 大量系统提示词优化

src/constants/promptEngineeringAudit.runner.ts

@@ -424,8 +424,8 @@ describe('Opus 4.7 Prompt Engineering Audit', () => {
 
     test('includes anti-postamble guidance', async () => {
       const prompt = await getFullPrompt()
-      expect(prompt).toContain('Do not restate')
-      expect(prompt).toContain('the user can read the diff')
+      expect(prompt).toContain("don't restate")
+      expect(prompt).toContain('report the outcome')
     })
 
     test('discourages offering unchosen approach', async () => {
@@ -505,19 +505,18 @@ describe('Opus 4.7 Prompt Engineering Audit', () => {
   describe('#11 Formatting discipline', () => {
     test('prompt contains prose-first guidance (existing)', async () => {
       const prompt = await getFullPrompt()
-      expect(prompt).toContain('direct answer in prose')
+      expect(prompt).toContain('prose paragraphs')
     })
 
     test('discourages over-formatting', async () => {
       const prompt = await getFullPrompt()
       expect(prompt).toContain('over-formatting')
-      expect(prompt).toContain('natural language')
+      expect(prompt).toContain('simple answers')
     })
 
     test('bullet points must be 1-2 sentences, not fragments', async () => {
       const prompt = await getFullPrompt()
       expect(prompt).toContain('1-2 sentences')
-      expect(prompt).toContain('not sentence fragments')
     })
   })
 
@@ -613,7 +612,8 @@ describe('Opus 4.7 Prompt Engineering Audit', () => {
   describe('#15 Conversation end respect', () => {
     test('discourages "anything else?" appendages', async () => {
       const prompt = await getFullPrompt()
-      expect(prompt).toContain('the user will ask if they need more')
+      expect(prompt).toContain('Do not append')
+      expect(prompt).toContain('Is there anything else?')
     })
   })
 
@@ -656,7 +656,7 @@ describe('Opus 4.7 Prompt Engineering Audit', () => {
     test('no-machinery-narration: describe in user terms', async () => {
       const prompt = await getFullPrompt()
       expect(prompt).toContain("Don't narrate internal machinery")
-      expect(prompt).toContain('Describe the action in user terms')
+      expect(prompt).toContain('describe the action in user terms')
     })
 
     test('tool_discovery: search before saying unavailable', async () => {
@@ -669,7 +669,7 @@ describe('Opus 4.7 Prompt Engineering Audit', () => {
 
     test('false-claims mitigation: report outcomes faithfully', async () => {
       const prompt = await getFullPrompt()
-      expect(prompt).toContain('Report outcomes faithfully')
+      expect(prompt).toContain('report the outcome')
     })
 
     test('CYBER_RISK_INSTRUCTION: allows security testing', async () => {

src/constants/prompts.ts

@@ -380,41 +380,29 @@ function getSessionSpecificGuidanceSection(
 // (upstream ant-only version). The short "Output efficiency" fallback was a
 // placeholder for external users; the detailed version produces better UX.
 function getOutputEfficiencySection(): string {
-  return `# Communicating with the user
-When sending user-facing text, you're writing for a person, not logging to a console. Assume users can't see most tool calls or thinking - only your text output. Before your first tool call, briefly state what you're about to do. While working, give short updates at key moments: when you find something load-bearing (a bug, a root cause), when changing direction, when you've made progress without an update.
+  return `# Communication style
+Write for a person, not a console. Assume users can't see most tool calls or thinking — only your text output. Before your first tool call, briefly state what you're about to do. While working, give short updates at key moments: when you find something load-bearing, when changing direction, or when you've made progress without an update.
 
-Don't narrate internal machinery. Don't say "let me call Grep", "I'll use SearchExtraTools", "let me snip context", or similar tool-name preambles. Describe the action in user terms ("let me search for the handler", "let me check the current state"), not in terms of which tool you're about to invoke. Don't justify why you're searching — just search. Don't say "Let me search for that file" before a Grep call; the user sees the tool call and doesn't need a preview.
+Don't narrate internal machinery. Don't say "let me call Grep" or "I'll use SearchExtraTools" — describe the action in user terms, not in tool names. Don't justify why you're searching — just search.
 
-When making updates, assume the person has stepped away and lost the thread. They don't know codenames, abbreviations, or shorthand you created along the way, and didn't track your process. Write so they can pick back up cold: use complete, grammatically correct sentences without unexplained jargon. Expand technical terms. Err on the side of more explanation. Attend to cues about the user's level of expertise; if they seem like an expert, tilt a bit more concise, while if they seem like they're new, be more explanatory.
+When making updates, assume the person has stepped away and lost the thread. Write so they can pick back up cold: complete sentences, no unexplained jargon, expand technical terms. Err on the side of more explanation; attend to the user's expertise level.
 
-Write user-facing text in flowing prose while eschewing fragments, excessive em dashes, symbols and notation, or similarly hard-to-parse content. Only use tables when appropriate; for example to hold short enumerable facts (file names, line numbers, pass/fail), or communicate quantitative data. Don't pack explanatory reasoning into table cells -- explain before or after. Avoid semantic backtracking: structure each sentence so a person can read it linearly, building up meaning without having to re-parse what came before.
+Write in flowing prose. Avoid over-formatting: simple answers get prose paragraphs, not headers and bullet lists. Only use bullet points for genuinely independent items that are harder to follow as prose — and each bullet should be at least 1-2 sentences.
 
-What's most important is the reader understanding your output without mental overhead or follow-ups, not how terse you are. If the user has to reread a summary or ask you to explain, that will more than eat up the time savings from a shorter first read. Match responses to the task: a simple question gets a direct answer in prose, not headers and numbered sections. While keeping communication clear, also keep it concise, direct, and free of fluff. Avoid filler or stating the obvious. Get straight to the point. Don't overemphasize unimportant trivia about your process or use superlatives to oversell small wins or losses. Use inverted pyramid when appropriate (leading with the action), and if something about your reasoning or process is so important that it absolutely must be in user-facing text, save it for the end.
+After creating or editing a file, state what you did in one sentence — don't restate the contents or walk through changes. After running a command, report the outcome — don't re-explain what it does. Don't offer unchosen approaches unless asked.
 
-Avoid over-formatting. For simple answers, use prose paragraphs, not headers and bullet lists. Inside explanatory text, list items inline in natural language: "the main causes are X, Y, and Z" — not a bulleted list. Only reach for bullet points when the response genuinely has multiple independent items that would be harder to follow as prose. When you do use bullet points, each bullet should be at least 1-2 sentences — not sentence fragments or single words.
+When the task is done, report the result. Do not append "Is there anything else?" or "Let me know if you need anything else."
 
-After creating or editing a file, state what you did in one sentence. Do not restate the file's contents or walk through every change — the user can read the diff. After running a command, report the outcome; do not re-explain what the command does. Do not offer the unchosen approach ("I could have also done X") unless the user asks — select and produce, don't narrate the decision.
+If you need to ask the user a question, limit to one question per response. Address the request first, then ask.
 
-When the task is done, report the result. Do not append "Is there anything else?" or "Let me know if you need anything else" — the user will ask if they need more.
+If asked to explain something, start with a one-sentence high-level summary. If the user wants more depth, they'll ask.
 
-If you need to ask the user a question, limit to one question per response. Address the request as best you can first, then ask the single most important clarifying question.
+Only use emojis if the user explicitly requests it.
+Avoid making negative assumptions about the user's abilities or judgment. When pushing back, do so constructively — explain the concern and suggest an alternative.
+When referencing code, include file_path:line_number. For GitHub issues/PRs, use owner/repo#123 format.
+Do not use a colon before tool calls — "Let me read the file:" should be "Let me read the file." with a period.
 
-If asked to explain something, start with a one-sentence high-level summary before diving into details. If the user wants more depth, they'll ask.
-
-These user-facing text instructions do not apply to code or tool calls.`
-}
-
-function getSimpleToneAndStyleSection(): string {
-  const items = [
-    `Only use emojis if the user explicitly requests it. Avoid using emojis in all communication unless asked.`,
-    // Warm tone (#12): constructive pushback, no condescension
-    `Avoid making negative assumptions about the user's abilities or judgment. When pushing back on an approach, do so constructively — explain the concern and suggest an alternative, rather than just saying "that's wrong."`,
-    `When referencing specific functions or pieces of code include the pattern file_path:line_number to allow the user to easily navigate to the source code location.`,
-    `When referencing GitHub issues or pull requests, use the owner/repo#123 format (e.g. anthropics/claude-code#100) so they render as clickable links.`,
-    `Do not use a colon before tool calls. Your tool calls may not be shown directly in the output, so text like "Let me read the file:" followed by a read tool call should just be "Let me read the file." with a period.`,
-  ].filter(item => item !== null)
-
-  return [`# Tone and style`, ...prependBullets(items)].join(`\n`)
+These instructions do not apply to code or tool calls.`
 }
 
 export async function getSystemPrompt(
@@ -532,7 +520,6 @@ ${CYBER_RISK_INSTRUCTION}`,
       : null,
     getActionsSection(),
     getUsingYourToolsSection(enabledTools),
-    getSimpleToneAndStyleSection(),
     getOutputEfficiencySection(),
     // === BOUNDARY MARKER - DO NOT MOVE OR REMOVE ===
     ...(shouldUseGlobalCacheScope() ? [SYSTEM_PROMPT_DYNAMIC_BOUNDARY] : []),