Though it is NOT, when you verify hashes with your eyes (and brain) manually, it sounds like a great optimization. After all, even minor changes in content should cause a completely different hash, right?
Unfortunately, that makes several assumptions that could be your undoing. Due to these assumptions, the reduced security is not a function of the reduced number of bits you're checking. But something else altogether, that is not easy to compute. But it is not likely a small impact.
- If you assume that the adversary is only making small changes. Most likely untrue, unless you're looking at a loan document that is only hashed (not digitally signed) where merely adding a few zeros to the loan amount is good enough impact.
- If you assume that the adversary won't attempt hash collisions, again it is likely untrue - coz the kind of people who tamper with documents usually have high stakes and it is usually worth their while to attempt. By reducing the bits by half, you are likely cutting down the effort of generating hash collisions from "100s of years" to "a few minutes/hours" (i.e., probability from ~0 to ~1) - not exactly a 50% reduction in security. This is how the first SHA1 collisions have been achieved, BTW - by reducing the effort needed (this arstechnica article talks about identical prefix attacks - in lay people terms - it means that if you know a good portion of the document in question, the effort is reduced significantly).
There are other issues too, but I believe this is enough reason to not go this route.
So I always use tools to do the check for me. e.g., Linux sha1sum and sha256sum not only generate the hashes (to verify manually) but given the 2nd input, they can verify and tell you if all is well.