[
  {
    "notice": "只有 title 和 text 字段是必填，其他字段可删除不填。填写时，请从第三条数据开始填写，第二条数据是示例，填写完成之后，不要删除前面两条",
    "notice1": "只有 title 和 text 字段是必填，其他字段可删除不填。填写时，请从第三条数据开始填写，第二条数据是示例，填写完成之后，不要删除前面两条",
    "notice2": "只有 title 和 text 字段是必填，其他字段可删除不填。填写时，请从第三条数据开始填写，第二条数据是示例，填写完成之后，不要删除前面两条",
    "title": "这里填标题，必填必填必填必填必填必填必填必填必填必填必填必填必填必填必填必填必填必填必填必填",
    "titleTranslate": "这里填标题翻译",
    "text": "这里填原文，一句一个换行符，一段两个换行符，必填必填必填必填必填必填必填必填必填必填必填必填必填必填必填必填必填必填必填必填",
    "textTranslate": "这里填原文翻译，一句一个换行符，一段两个换行符",
    "audioSrc": "这里填音频的url/在线地址"
  },
  {
    "title": "How are you today?",
    "titleTranslate": "今天好吗？",
    "text": "STEVEN:Hello, HELEN.\n\nHELEN:Hi, Steven.\n\nSTEVEN:How are you today?\n\nHELEN:I'm very well, thank you. And you?\n\nSTEVEN:I'm fine, thanks.\n\nSTEVEN:How is Tony?\n\nHELEN:He's fine, thanks. How's Emma?\n\nSTEVEN:She's very well, too, Helen.\n\nSTEVEN:Goodbye, Helen.Nice to see you.\n\nHELEN:Nice to see you, too, Steven. Goodbye.",
    "textTranslate": "史蒂文：你好，海伦 \n\n海 伦：你好，史蒂文 \n\n史蒂文：你今天好吗？ \n\n海 伦：很好，谢谢你。你好吗？ \n\n史蒂文：很好，谢谢。 \n\n史蒂文：托尼好吗？ \n\n海 伦：他很好，谢谢。埃玛好吗？ \n\n史蒂文：她也很好，海伦。 \n\n史蒂文：再见，海伦。见到你真高兴。 \n\n海 伦：我见到你也很高兴，史蒂文。再见。",
    "audioSrc": "/sound/article/nce1/009&010－How Are You Today.mp3"
  },
  {
    "title": "04A Defining the First Useful Version",
    "titleTranslate": "第04课A｜说清楚我想要什么",
    "text": "Before I ask someone to build a feature, I need to describe the result that I want a user to achieve.\nFor a content tool, the goal might be to find relevant posts, prepare a reply, and choose a suitable publishing time.\nThese activities form the core workflow, and every additional requirement should have a clear connection to that practical goal.\nI would like the first version to support account connections and scheduling, but I do not need advanced reports immediately.\nThe difference between a necessary function and an interesting extra becomes important when time and attention are limited.\nI write the requirements as observable actions so that another person can tell when the work is complete.\nFor example, a user should be able to select a date and save a post without publishing it immediately.\nWe must also explain the limits, including which accounts are supported and what happens when an external service is unavailable.\nClear limits make the first version easier to review and reduce the chance of different people imagining different products.\nI can always expand the scope later, after the basic workflow has proved useful in real situations and ordinary daily tasks.\nA clear example makes those boundaries easier for everyone to understand.",
    "textTranslate": "请别人开发功能前，我需要说明希望用户取得的结果。\n内容工具的目标可能是找相关帖子、准备回复并选择发布时间。\n这些活动构成核心流程，每项额外需求都应与实际目标清楚关联。\n我希望第一版支持账号连接和排期，但不需要立即提供高级报告。\n时间和精力有限时，必要功能与有趣附加项的区别很重要。\n我把需求写成可观察动作，让别人知道何时算完成。\n例如用户应该能选择日期并保存帖子，而不立即发布。\n我们也必须说明限制，包括支持哪些账号及外部服务不可用时会怎样。\n清晰边界让初版更易检查，减少不同人想象不同产品的机会。\n基本流程在真实场景和日常任务中证明有用后，我可以再扩大范围。\n清晰例子让所有人更易理解边界。"
  },
  {
    "title": "04B Keeping the Scope Clear",
    "titleTranslate": "第04课B｜说清楚我想要什么",
    "text": "A request can sound simple while leaving several important decisions hidden, especially when it uses broad words such as improve or automate.\nIf I say that a tool should automate content, someone still needs to know which actions the tool should actually perform.\nShould it suggest topics, write complete posts, schedule approved content, or publish without asking for a final review first?\nI separate these choices and describe what belongs in the first release, what can wait, and what requires a human decision.\nI also distinguish between things the system can do and things it is allowed to do on someone's behalf.\nA feature may be technically possible without being necessary for the current goal or appropriate for the current audience.\nWhen the scope is written clearly, it becomes easier to ask focused questions instead of repeatedly changing the entire plan.\nA useful requirement might say that the application can save a draft but must not publish it until the user confirms.\nThis statement gives us a visible action, a meaningful limit, and a practical way to review whether the implementation is correct.\nThe first release does not need every possible function; it needs enough carefully chosen functions to support one complete and useful workflow.",
    "textTranslate": "请求使用改进或自动化等宽泛词时，听起来简单却可能隐藏重要决定。\n如果我说工具应该自动处理内容，仍需说明它具体执行哪些动作。\n它应建议话题、撰写整篇帖子、排期已批准内容，还是不经最终审阅直接发布？\n我拆开这些选择，说明首发包含什么、什么能等、什么需要人工决定。\n我也区分系统能够做什么，以及获准代表他人做什么。\n功能技术上可行，不代表符合当前目标或受众需要。\n范围写清楚后，就更容易集中提问，不用反复修改整个计划。\n实用需求可以写成：应用能保存草稿，但用户确认前不得发布。\n这句话提供可见操作、有意义限制，以及检查实现是否正确的方法。\n首发不必拥有所有可能功能，只需精心选择足够功能支撑一条完整实用流程。"
  },
  {
    "title": "04C Working Conversation",
    "titleTranslate": "第04课C｜说清楚我想要什么",
    "text": "Builder: You asked for a content tool; could you explain the main result you want a user to achieve in the first version?\nOwner: I want users to find relevant posts, connect an account, prepare content, and choose when an approved post should be published.\nBuilder: Should the application write everything automatically, or do you want people to review the content before it becomes public?\nOwner: People must review it first; the tool should save drafts and handle scheduling, but it must not make that final decision.\nBuilder: Do we need detailed reports in the initial release, or can we leave that work until the basic workflow is useful?\nOwner: We can leave reports for later; I would rather finish a complete small workflow than add several features that remain unfinished.\nBuilder: I will write down these requirements and explain the limits before implementing the first feature or connecting any external accounts.\nOwner: Good; please include a concrete example so that we can check the result against the same clear expectations at the end.",
    "textTranslate": "开发者：你想做内容工具，能说明第一版要让用户获得什么主要结果吗？\n负责人：我希望用户找到相关帖子、连接账号、准备内容，并选择已批准帖子的发布时间。\n开发者：应用应自动写全部内容，还是要人工审阅后才能公开？\n负责人：必须先审阅，工具保存草稿并处理排期，但不作最终决定。\n开发者：初版需要详细报告吗，还是等基本流程有用再做？\n负责人：报告可以以后做，我宁愿完成小流程，也不想添加几个未完成功能。\n开发者：实现功能或连接外部账号之前，我会记录需求并解释限制。\n负责人：好，请附上具体例子，让我们最终能按同一明确预期检查。"
  },
  {
    "title": "04D Sentence Review",
    "titleTranslate": "第04课D｜说清楚我想要什么",
    "text": "Before I ask someone to build a feature, I need to describe the result that I want a user to achieve.\nThese activities form the core workflow, and every additional requirement should have a clear connection to that practical goal.\nThe difference between a necessary function and an interesting extra becomes important when time and attention are limited.\nWe must also explain the limits, including which accounts are supported and what happens when an external service is unavailable.\nA request can sound simple while leaving several important decisions hidden, especially when it uses broad words such as improve or automate.\nShould it suggest topics, write complete posts, schedule approved content, or publish without asking for a final review first?\nA feature may be technically possible without being necessary for the current goal or appropriate for the current audience.\nThis statement gives us a visible action, a meaningful limit, and a practical way to review whether the implementation is correct.\nYou asked for a content tool; could you explain the main result you want a user to achieve in the first version?\nShould the application write everything automatically, or do you want people to review the content before it becomes public?\nDo we need detailed reports in the initial release, or can we leave that work until the basic workflow is useful?\nI will write down these requirements and explain the limits before implementing the first feature or connecting any external accounts.",
    "textTranslate": "请别人开发功能前，我需要说明希望用户取得的结果。\n这些活动构成核心流程，每项额外需求都应与实际目标清楚关联。\n时间和精力有限时，必要功能与有趣附加项的区别很重要。\n我们也必须说明限制，包括支持哪些账号及外部服务不可用时会怎样。\n请求使用改进或自动化等宽泛词时，听起来简单却可能隐藏重要决定。\n它应建议话题、撰写整篇帖子、排期已批准内容，还是不经最终审阅直接发布？\n功能技术上可行，不代表符合当前目标或受众需要。\n这句话提供可见操作、有意义限制，以及检查实现是否正确的方法。\n开发者：你想做内容工具，能说明第一版要让用户获得什么主要结果吗？\n开发者：应用应自动写全部内容，还是要人工审阅后才能公开？\n开发者：初版需要详细报告吗，还是等基本流程有用再做？\n开发者：实现功能或连接外部账号之前，我会记录需求并解释限制。"
  },
  {
    "title": "04E Vocabulary in Context",
    "titleTranslate": "第04课E｜说清楚我想要什么",
    "text": "The initial release must be compliant with the agreed requirements, including any explicit limit on automated actions.\nAn auto mode may sound convenient, but users must understand which actions are automated and which require a decision.\nWe considered a different implementation, but the selected approach covers the core requirement with less complexity.\nBefore we implement an option, we should consider its effect on the whole workflow rather than one attractive feature.\nThe system allows users to set a target, and it must clearly explain what happens when they reach it.\nA bounded task has an explicit limit, while an undefined task may expand in an unintended direction.\nA non-unique name is allowed here, but this field requires a unique identifier for each record.\nWe rejected several fancy additions because the basic product did not depend on them.",
    "textTranslate": "初版必须符合约定需求，包括自动操作明确限制。\n自动模式虽方便，用户必须知道哪些操作自动、哪些需决定。\n我们考虑过另一实现，但当前方式更简单地涵盖核心需求。\n实现方案前应考虑整体流程影响，而非单个诱人功能。\n系统允许设目标，必须清楚说明达标后会怎样。\n有界任务有明确限制，未定义任务可能意外扩张。\n此处允许重名，但该字段要求每条记录标识唯一。\n我们拒绝几个花哨附加项，因为基本产品不依赖它们。"
  }
]