📖

Book Review (读后感) Template: Structure and a Full Example

A book review (读后感) says what the book is about, what in it struck you and why, where you agree or disagree, what you will do differently and who should read it. It is about the reader's thinking as much as the book, which is why summaries alone fail.

Get these right before you write

  1. 1Summarise the book in one paragraph; the review is not a retelling.
  2. 2Pick two or three ideas and say why they struck you, with a quote each.
  3. 3Disagreement, argued, is the most valuable part.
  4. 4End with a change: something you will do, or stop doing.

Structure

The document opens with these headings and blanks.

[Book] — a review
##What it is about
[...]
##What struck me
[idea — why]
##Where I agree, where I do not
[...]
##What I take away
[...]
##Who should read it
[...]

A complete example

Written by the AI from this brief, exactly as the workbench would write yours:

A review of 'The Checklist Manifesto' by Atul Gawande, written by a customer-support team lead: the book argues that simple checklists prevent expert failure, with examples from surgery and aviation; what struck her was the distinction between checks of ignorance and checks of ineptitude, and the pause points; she disagrees that checklists suit creative work; she will build a three-item handover checklist for shift changes; recommended to anyone who runs a team.

The Checklist Manifesto by Atul Gawande: A Review

What the Book Is About

Atul Gawande, a surgeon, sets out to answer a simple question: why do highly trained experts still fail, and what can be done about it? His answer is that the volume and complexity of modern knowledge has outgrown any single person's ability to hold it all reliably in their head. The fix he proposes is almost embarrassingly modest: the checklist. Drawing on examples from aviation, where pilots have used pre-flight checklists since the 1930s, and from his own work on a surgical safety checklist that cut complications and deaths in hospitals around the world, Gawande argues that a short, well-designed list of checks catches the small omissions that cause big failures. The book is short, anecdotal and persuasive, and it spends as much time on how to write a good checklist as on why you need one.

The Ideas That Struck Me

Ignorance versus ineptitude

Gawande borrows a distinction between two kinds of failure. Errors of ignorance happen because we genuinely do not know enough. Errors of ineptitude happen because we do know enough, but fail to apply it correctly or consistently. His point is that in most skilled work today, the second kind now dominates the first. This landed hard for me. When something goes wrong on my support team, it is almost never because nobody knew the right answer. It is because the person who knew it was tired, rushed, or assumed someone else had handled it. Checklists do nothing for ignorance, but they are built for ineptitude.

Pause points

The second idea I keep coming back to is the pause point: a defined moment in a process where the work stops, the checklist is read, and only then does the work continue. In surgery this is the moment before incision; in aviation it is before takeoff. What struck me is that the pause point matters as much as the list itself. A checklist nobody is required to stop and read is just a document. The discipline is in choosing the moment when the team is forced to look up.

Keep it short

The third point is less a single idea than a recurring warning: long checklists fail. Gawande describes early drafts of the surgical checklist that were too detailed, too slow, and quietly ignored. The versions that worked were brief, focused on the steps most often missed, and worded so they could be read aloud in under a minute. This is a useful corrective for anyone, like me, whose first instinct is to document everything.

Where I Agree and Disagree

I agree with the core argument. The evidence from surgery and aviation is hard to argue with, and the idea that experts need help with the routine rather than the exceptional rings true from my own experience running a team.

Where I part ways with Gawande is in how far he stretches the idea. He suggests checklists can support even creative and improvisational work, and I am not convinced. A checklist works when the steps are known and the failure modes are predictable. The hardest parts of support work, and of most knowledge work, are the unpredictable ones: the angry customer with a problem nobody has seen before, the judgement call about when to escalate. A checklist can get you to the starting line in good shape, but it cannot make the call for you, and I think the book underplays that limit.

What I Will Do Differently

The most common failure on my team is the handover between shifts. Context gets lost, open tickets get forgotten, and the incoming team spends the first hour rediscovering what the outgoing team already knew. After reading this book, I am going to build a three-item handover checklist, read aloud at the shift change, which is our natural pause point:

  1. Which open tickets are waiting on a customer, and which are waiting on us?
  2. Is there any ongoing incident or known issue the incoming shift must watch?
  3. Is there anything the outgoing shift promised a customer that has not yet been done?

Three items, under a minute, nothing more. If it works, I will resist the temptation to grow it.

Who Should Read It

Anyone who runs a team. You do not need to work in medicine or aviation; the lessons transfer directly to any setting where capable people must coordinate under time pressure. It is a quick read, and the practical guidance on writing a checklist that people will actually use is worth the price on its own.

Names, figures and dates in the example are made up for illustration.

How it works

  1. 1Open the template: a document with the skeleton and the brief appears.
  2. 2Add one line about your case to the brief, or attach your notes as sources, and press First draft.
  3. 3Edit directly, or ask the AI to tighten, expand or translate any passage; every AI change is reviewed before it lands.

Questions

Can I use the example as it is?
The example shows the shape and tone; its names and figures are made up. Open the template and give the AI your own facts, and it writes yours in the same shape.
Does it work in English and Chinese?
Yes. The document is written in the language of your brief, and any passage can be translated afterwards.
Is it free?
Writing is billed by the tokens used, usually a few credits per draft; the template, the skeleton and the editor cost nothing.

Other documents in this group

All everyday documents (27) →